Teknologian jakaminen

Design Pattern Builder Pattern

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Suunnittelukuvioiden Builder Pattern on yleisesti käytetty objektin luomisen suunnittelumalli, jota käytetään pääasiassa monimutkaisten objektien rakennusongelmien ratkaisemiseen. Tässä on yksityiskohtainen johdatus rakentajatilaan:

1. Määritelmä

Rakennusmalli erottaa monimutkaisen objektin rakentamisen sen esityksestä, jolloin sama rakennusprosessi voi luoda erilaisia ​​esityksiä. Toisin sanoen se toimii jakamalla monimutkaisten objektien rakennusprosessin yksinkertaisiin vaiheisiin ja sallimalla käyttäjien luoda erilaisia ​​objekteja määrittämällä näiden vaiheiden järjestyksen ja parametrit.

2. Luokkakaavio ja rakenne

Luokkakaavio

Rakennustilassa seuraavat roolit ovat yleensä mukana:

  1. Tuotteen rooli (tuote): Edustaa rakennettavaa monimutkaista objektia, joka sisältää yleensä useita komponentteja.
  2. Abstrakti rakentaja: Määritä abstrakti käyttöliittymä tuoteobjektien eri komponenttien luomiseen.
  3. ConcreteBuilder: Toteuta Builder-käyttöliittymä, viimeistele monimutkaisen tuotteen kunkin komponentin erityiset luontimenetelmät ja määritä käyttöliittymä, joka palauttaa lopullisen tuotteen.
  4. Johtaja : Vastaa rakentajaobjektin komponenttien rakennus- ja kokoonpanomenetelmien kutsumisesta monimutkaisten objektien luomisen viimeistelemiseksi. Se ei sisällä tuotekohtaisia ​​tietoja, vaan yksinkertaisesti erottaa asiakkaan rakentajasta.

3. Sovellettavat skenaariot

Builder-kuvio sopii seuraaviin skenaarioihin:

  1. Objektirakenne on monimutkainen: Kun rakennettavalla objektilla on monimutkainen sisäinen rakenne ja se sisältää useita ominaisuuksia ja menetelmiä, rakentajamallin käyttö voi yksinkertaistaa rakennusprosessia.
  2. Rakennusprosessi on monimutkainen: Kun kohteen rakennusprosessi sisältää useita vaiheita ja näiden vaiheiden järjestys ja parametrit voivat olla erilaisia, rakentajamalli voi tarjota selkeän rakennusprosessin.
  3. Irrotettu luominen ja käyttö: Kun haluat erottaa objektien luonti- ja käyttöprosessit siten, että käyttäjien tarvitsee välittää vain objektin lopullisesta esityksestä eikä objektin luomisen yksityiskohdista, rakentajamalli on hyvä valinta.

4. Edut ja haitat

etu
  1. Hyvä kapselointi: Kapseloi monimutkaisten kohteiden rakennusprosessi rakentajan sisällä. Asiakkaan tarvitsee vain määritellä rakennuksen tyyppi ja parametrit saadakseen lopputuotteen tietämättä rakennusprosessin yksityiskohtia.
  2. Hyvä skaalautuvuus: Jos sinun on lisättävä uusi koontityyppi tai muutettava koontiprosessia, sinun tarvitsee vain lisätä tai muokata rakentajaluokkaa, mikä ei vaikuta asiakaskoodiin.
  3. Korkea joustavuus: Joustavuus luoda erilaisia ​​tuoteilmentymiä muuttamalla rakentajan rakennusjärjestystä tai parametreja.
puute
  1. Lisää luokkien määrää: Koska on tarpeen luoda useita luokkia, kuten rakentajaliitäntöjä, tiettyjä rakentajaluokkia ja komentajaluokkia, järjestelmän luokkien määrää voidaan lisätä.
  2. Vaikeus sisäisessä muuttamisessa: Jos tuotteen sisäinen rakenne muuttuu, useita rakentajaluokkia voi olla tarpeen muuttaa, mikä lisää järjestelmän ylläpitokustannuksia.

5. Esimerkki

Seuraavassa esimerkissä käytämme Builder-mallia talon remontointijärjestelmän suunnittelussa.Määrittelemme aHouse Luokat ovat monimutkaisia ​​esineitä, jotka sisältävät useita sisustuskomponentteja (kuten katot, maalit, lattiat, lattialaatat jne.).Sitten määrittelemme aHouseBuilder Käyttöliittymä, joka sisältää abstrakteja menetelmiä näiden komponenttien luomiseksi. Seuraavaksi luomme erityiset rakennusluokat kullekin tietylle sisustustyylille (kuten ylellinen eurooppalainen tyyli, kevyt luksuspastoraali, moderni minimalistinen).Lopuksi ohitamme aDirectorluokka ohjaamaan rakennusprosessia, mutta se ei ehkä ole tarpeen tässä esimerkissä, koska voimme määritellä täydellisen rakennuslogiikan suoraan rakentajaluokassa.

Kuitenkin osoittaaksemme kapellimestariroolin käsitteen, säilytämme aDirectorluokkaan, mutta vain havainnollistamistarkoituksessa rakennusprosessi voidaan tehdä suoraan rakentajaluokassa.

  1. // 房屋类
  2. public class House {
  3. private String ceiling; // 吊顶
  4. private String paint; // 涂料
  5. private String floor; // 地板
  6. private String tiles; // 地砖
  7. // 私有构造函数
  8. private House() {}
  9. // Getter 方法
  10. public String getCeiling() {
  11. return ceiling;
  12. }
  13. public String getPaint() {
  14. return paint;
  15. }
  16. public String getFloor() {
  17. return floor;
  18. }
  19. public String getTiles() {
  20. return tiles;
  21. }
  22. // 建造者接口
  23. public interface HouseBuilder {
  24. HouseBuilder buildCeiling(String ceiling);
  25. HouseBuilder buildPaint(String paint);
  26. HouseBuilder buildFloor(String floor);
  27. HouseBuilder buildTiles(String tiles);
  28. House build();
  29. }
  30. // 豪华欧式建造者 ,注意是静态内部类
  31. public static class LuxuryEuropeanBuilder implements HouseBuilder {
  32. private House house;
  33. public LuxuryEuropeanBuilder() {
  34. this.house = new House();
  35. }
  36. @Override
  37. public HouseBuilder buildCeiling(String ceiling) {
  38. house.ceiling = "豪华欧式吊顶: " + ceiling;
  39. return this;
  40. }
  41. @Override
  42. public HouseBuilder buildPaint(String paint) {
  43. house.paint = "豪华欧式涂料: " + paint;
  44. return this;
  45. }
  46. @Override
  47. public HouseBuilder buildFloor(String floor) {
  48. house.floor = "豪华欧式地板: " + floor;
  49. return this;
  50. }
  51. @Override
  52. public HouseBuilder buildTiles(String tiles) {
  53. house.tiles = "豪华欧式地砖: " + tiles;
  54. return this;
  55. }
  56. @Override
  57. public House build() {
  58. return house;
  59. }
  60. }
  61. // ... 可以为其他风格创建类似的建造者类
  62. // 指挥者类(可选,这里主要用于展示概念)
  63. public static class Director {
  64. private HouseBuilder builder;
  65. public Director(HouseBuilder builder) {
  66. this.builder = builder;
  67. }
  68. // 这里可以添加方法来指导建造过程,但在这个例子中,我们直接在建造者中完成了所有工作
  69. public House constructHouse() {
  70. // 假设这是由指挥者指导的步骤,但在这里我们直接返回建造者的结果
  71. return builder
  72. .buildCeiling("水晶吊灯")
  73. .buildPaint("金色镶边涂料")
  74. .buildFloor("大理石地板")
  75. .buildTiles("马赛克地砖")
  76. .build();
  77. }
  78. }
  79. // 主函数,用于演示
  80. public static void main(String[] args) {
  81. HouseBuilder luxuryBuilder = new LuxuryEuropeanBuilder();
  82. // Director director = new Director(luxuryBuilder); // 如果使用指挥者
  83. House house = luxuryBuilder
  84. .buildCeiling("水晶吊灯")
  85. .buildPaint("金色镶边涂料")
  86. .buildFloor("大理石地板")
  87. .buildTiles("马赛克地砖")
  88. .build();
  89. System.out.println("Ceiling: " + house.getCeiling());
  90. System.out.println("Paint: " + house.getPaint());
  91. System.out.println("Floor: " + house.getFloor());
  92. System.out.println("Tiles: " + house.getTiles());
  93. }
  94. }

Huomaa, että tässä esimerkissäDirectorLuokat eivät itse asiassa tuo paljon lisäarvoa, koska kaikki rakennuslogiikka on jo koteloituHouseBuilder Käyttöliittymä on toteutettu. Mutta monimutkaisemmissa sovelluksissaDirectorLuokkia voidaan käyttää rakennusprosessin järjestyksen ja logiikan kapseloimiseen, varsinkin kun rakennusprosessi kattaa useita rakentajia.

6. Johtopäätös

Yllä olevasta johdannosta voidaan nähdä, että rakentajamallilla on suuria etuja rakennettaessa monimutkaisia ​​objekteja. Se parantaa koodin kapselointia ja skaalautuvuutta erottamalla rakennusprosessin esityksestä ja vähentää myös viestintää asiakkaan ja tietyn välillä. välinen kytkentäaste.

Jos tästä artikkelista on hyötyä tutkimuksessasi, muista tykätä ja kerätä se.