Строитель: отделяйте построение сложного объекта от его представления, чтобы один и тот же процесс строительства мог создавать различные представления.
Используйте сценарии:
Общая классная диаграмма:
Например: много устройств в нашей жизни существует в форме сборки, таких как настольные компьютеры. Некоторые производители запустит несколько собранных компьютерных хостов с конфигурациями по умолчанию (режим метода шаблона можно использовать здесь). Клиенты могут приобрести продукты с конфигурациями по умолчанию, или они могут попросить производителей собрать хост с различными конфигурациями и методами сборки. На этом этапе мы можем использовать модель Builder для удовлетворения требований специальных клиентов.
Обратите внимание, что в этом примере производитель собирает хост, то есть основное внимание уделяется каждому компоненту хоста, который соответствует сценарию использования, указанному в режиме Builder выше.
Простая реализация кода выглядит следующим образом:
// абстрактный класс продукта, используя режим метода шаблона, разные продукты имеют разные «компонентные части» абстрактного класса AbstractProduct {Protected Abstract void part01 (); Защищенная абстрактная void part02 (); Защищенная абстрактная void part03 (); // Метод шаблона дает метод сборки по умолчанию, генерируя продукт по умолчанию Public Final AbstractProduct defaultProduct () {part01 (); part02 (); part03 (); вернуть это; // возвращать текущий объект, то есть продукт с методом сборки по умолчанию}} // конкретные продукты A и B, различные продукты реализуют различные «компонентные части» класса ConcreteProducta расширяет AbstractProduct {Protected void part01 () {System.out.println («Продукт a: part01 () ...»); } защищенный void part02 () {System.out.println ("Продукт a: part02 () ..."); } защищенный void part03 () {System.out.println ("Продукт a: part03 () ..."); }} class concretepRoductb extends artacyproduct {protected void part01 () {System.out.println ("Продукт b: part01 () ..."); } защищенный void part02 () {System.out.println ("Продукт b: part02 () ..."); } защищенный void part03 () {System.out.println ("Продукт b: part03 () ..."); }} // абстрактный строитель, формулирует метод комбинации, который каждый продукт должен реализовать BuildPart () и стандарт для производства BuildProduct () Abstract Class AbstractBuilder {public assoile void buildpart (); Public AbstractProduct BuildProduct (); } / * * Если конкретный строитель не удовлетворен продуктом по умолчанию (то есть, когда называется метод DefaultProduct () в абстрактном продукте), * вы не можете вызвать его для получения продукта, но используйте специфический строитель, чтобы изменить метод производства и сборки продукта, чтобы получить различные продукты * / class concreteBuildera расширяет AbstractBuilder {private AbstractProduct ProductA = NewCetep (Private AbstractProduct ProductA = NewCetep; public void buildpart () {this.producta.part03 (); this.producta.part02 (); this.producta.part01 (); } public AbstractProduct buildProduct () {return this.producta; }} class concreteBuilderb Extens AbstractBuilder {private AbstractProduct ProductB = new ConcretEproductb (); public void buildpart () {this.productb.part02 (); this.productb.part01 (); // Один компонент в продукте B пропущен, например, функции этой части не нужны клиентам // this.productb.part03 (); } public AbstractProduct buildProduct () {return this.productb; }} // Класс директоров, строитель, который предварительно удерживает каждый продукт, предоставляет различные методы сборки для пользователей, которые нуждаются в разных продуктах, чем директор по умолчанию класса продукта {Private AbstractBuilder Builda = new ConcreteBuildera (); Частный AbstractBuilder buildb = new ConceteBuilderb (); public AbstractProduct getProducta () {this.buildera.buildpart (); вернуть это.buildera.buildProduct (); } public AbstractProduct getProductb () {this.builderb.buildPart (); вернуть это.builderb.buildProduct (); }} // Тестовый класс публичный класс client {public static void main (string [] args) {System.out.println ("Использовать режим метода шаблона для получения продукта по умолчанию A"); AbstractProduct defaultProducta = new ConceteProducta (). DefaultProduct (); System.out.println ("/nuse Director Class для получения продукта A с различными методами сборки"); Директор директора = новый директор (); Director.getProducta (); System.out.println ("/nuse Director Class для получения продукта B с различными методами сборки"); Director.getProductb (); }} Результаты теста:
Используйте режим метода шаблона для получения продукта по умолчанию A
Продукт A: part01 () ...
Продукт A: part02 () ...
Продукт A: part03 () ...
Используйте класс директора для получения продуктов с различными методами сборки A
Продукт A: part03 () ...
Продукт A: part02 () ...
Продукт A: part01 () ...
Используйте класс директора для получения продукта B с различными методами сборки
Продукт B: part02 () ...
Продукт B: part01 () ...
Фактически, в этом примере категория продукта использует режим метода шаблона, упомянутый в предыдущей статье, то есть DefaultProduct () предоставляет метод сборки компонента по умолчанию продукта.
Но у меня здесь есть вопрос. Так называемый метод сборки по умолчанию, предоставленный в классе AbstractProduct на основе шаблона метода шаблона, предназначен для распечатки нескольких тестовых предложений, и он на самом деле не возвращает конкретный продукт. Тем не менее, я не знаю, является ли метод обработки возврата текущего объекта (вернуть это;) в приведенном выше примере разумным?
Кроме того, после написания этих статей об реализации шаблонов проектирования с кодом Java я обнаружил, что этот шаблон строителя строителей, по -видимому, сочетает в себе абстрактный заводской шаблон и шаблон метода шаблона. В приведенном выше абзаце уже упоминается мои сомнения. Что касается абстрактной заводской модели, я лично считаю, что класс директоров в приведенном выше примере кода очень похож на конкретный заводский класс абстрактной фабрики, но класс директоров также должен построить метод сборки продукта, прежде чем возвращать продукт. Возможно, именно эта «сборка» делает модель застройщика фокусироваться на сборке различных частей продукта, в то время как модель абстрактной заводской модели фокусируется только на генерации конечного продукта.
Я читал предложение раньше и сказал, что примерно сказано: если какая -либо проблема с компьютером трудно решить, с ним можно обработать, добавив промежуточный слой. Теперь, когда я думаю об этом, кажется, что как абстрактная фабрика, так и режим застройщика используют этот «принцип» для достижения желаемого эффекта. Например, в абстрактной фабрике есть абстрактный фабричный класс, и в строитель есть класс директоров. В конечном счете он заключается в том, чтобы инкапсулировать и скрыть определенные детали и отделить их от реализации и использования.
Я думаю, что вы должны сначала понять проблемы и применимые сценарии каждой модели, прежде чем вы сможете лучше понять их.
Возможно, все эти режимы являются творческими режимами, и у меня нет никакого практического опыта, что меня немного смущает ... Я не боюсь, немного размышляя в процессе реализации их всех, и медленно применение их к реальности должно постепенно понимать.
Выше приведено все об этой статье, и я надеюсь, что она вдохновит вас учиться.