Объекты шаблоны и методики программирования 5 издание скачать

Чем сложнее приложение. Тем выше сложность используемых классов и объектов. Сложные объекты состоят из частей. Произведенных другими объектами. Которые нуждаются в особом уходе при строительстве. Приложение может нуждаться в механизме построения сложных объектов. Который не зависит от тех. Которые составляют объект. Если это проблема. С которой вы столкнулись. Вы можете попробовать использовать шаблон проектирования Builder (или Adaptive Builder).

Этот паттерн позволяет объекту клиента построить сложный объект. Указав только его тип и содержание. Будучи экранированным от деталей. Связанных с представлением объекта.

Таким образом. Процесс построения может быть использован для создания различных представлений. Логика этого процесса изолирована от фактических шагов. Используемых при создании сложного объекта. Поэтому процесс может быть использован снова для создания другого объекта из того же набора простых объектов. Что и первый.

Намерение

  • Определяет экземпляр для создания объекта. Но позволяет подклассам решать. Какой класс создавать
  • Относится к вновь созданному объекту через общий интерфейс

Реализация

Шаблон проектирования Builder использует шаблон Factory Builder. Чтобы решить. Какой конкретный класс инициировать. Чтобы построить нужный тип объекта. Как мы увидим ниже на диаграмме UML:

Шаблон компоновщика - Диаграмма классов UML

Классы участников в этом шаблоне:

  • Класс Builder задает абстрактный интерфейс для создания частей объекта продукта.
  • ConcreteBuilder создает и объединяет части продукта. Реализуя интерфейс Builder. Он определяет и отслеживает создаваемое представление и предоставляет интерфейс для сохранения продукта.
  • Класс Director создает сложный объект с помощью интерфейса Builder.
  • Продукт представляет собой сложный объект. Который строится.

Клиент, который может быть либо другим объектом. Либо фактическим клиентом. Вызывающим метод main() приложения. Инициирует класс Builder и Director.

Конструктор представляет собой сложный объект. Который должен быть построен в терминах более простых объектов и типов. Конструктор в классе Director получает объект Builder в качестве параметра от Клиента и отвечает за вызов соответствующих методов класса Builder. Чтобы предоставить Клиенту интерфейс для всех конкретных Строителей. Класс Builder должен быть абстрактным. Таким образом. Вы можете добавлять новые типы сложных объектов. Только определяя структуру и повторно используя логику для фактического процесса построения.

Клиент-единственный. Кто должен знать о новых типах. Директор должен знать. Какие методы Строителя вызывать. В следующем примере рассматривается случай приложения преобразования текста:
Пример шаблона компоновщика - Диаграмма классов UML

Клиенту необходимо преобразовать документ из формата RTF в формат ASCII. Там для, он вызывает метод createASCIIText. Который принимает в качестве параметра документ. Который будет преобразован. Этот метод вызывает конкретный компоновщик. ASCIIConverter. Который расширяет Компоновщик. TextConverter. И переопределяет его два метода преобразования символов и абзацев. А также директор, RTFReader. Который анализирует документ и вызывает методы компоновщика в зависимости от типа обнаруженного токена.

Продукт, ASCIIText. Создается шаг за шагом. Путем добавления преобразованных символов.

// Класс продукта ASCIIText{ //Concrete Builder class ASCIIConverter расширяет TextConverter{ ASCIIText asciiTextObj;//результирующий продукт /*преобразует символ в целевое представление и добавляет его к результирующему*/ object void convertCharacter(char c){ ASCIIText GetResult(){ //Этот класс абстрагирует документ класса объектов Document{ static int value; токен char; public char getNextToken(){ //Director class RTFReader{ private static final char EOF='0'; //Разделитель для конца файла final char CHAR='c'; 

final char PARA='p'; char t; Конструктор текстовых преобразователей; RTFReader(TextConverter obj){ builder=obj; } void parseRTF(Document doc){ while ((t=doc.getNextToken())!= EOF){ switch (t){ case CHAR: builder.convertCharacter(t); //Клиент публичный класс Клиент{ void createASCIIText(Документ doc){ ASCIIConverter asciiBuilder = новый ASCIIConverter(); RTFReader RTFReader = новый RTFReader(asciiBuilder); RTFReader.parseRTF(doc); public static void main(String args[]){

Клиент клиент=новый клиент(); Документ doc=новый документ(); client.createASCIIText(doc);

Применимость и Примеры

Шаблон строителя используется, когда:

  • алгоритм создания сложного объекта не зависит от частей. Которые фактически составляют объект
  • система должна допускать различные представления для строящихся объектов

Пример 1 — Производитель транспортного средства.

Возьмем пример производителя транспортных средств. Который из набора деталей может построить автомобиль, велосипед. Мотоцикл или скутер. В этом случае Строитель станет Транспортником. Он определяет интерфейс для построения любого из транспортных средств в приведенном выше списке. Используя один и тот же набор деталей и другой набор правил для каждого типа транспортного средства.

Бетонщики будут строителями. Прикрепленными к каждому из строящихся объектов. Продукт-это, конечно, автомобиль. Который строится. А директор-производитель и его магазин.

Пример 1 — Экзамены студентов.

Если у нас есть приложение. Которое может быть использовано студентами университета. Чтобы предоставить им список своих оценок для экзаменов. Это приложение должно работать по-разному в зависимости от пользователя. Который его использует. Пользователя. Который должен войти в систему.

Это означает. Что, например. У администратора должны быть включены некоторые кнопки, кнопки. Которые должны быть отключены для студента. Обычного пользователя. Конструктор предоставляет интерфейс для построения формы в зависимости от регистрационной информации. ConcreteBuilders — это конкретные формы для каждого типа пользователей. Продукт-это окончательная форма. Которую приложение будет использовать в данном случае. А Директор-это приложение. Которое. Основываясь на регистрационной информации. Нуждается в определенной форме.

Конкретные проблемы и реализация

Строитель и Абстрактная фабрика

Паттерн проектирования Builder в некоторой степени очень похож на паттерн Абстрактной фабрики. Вот почему так важно уметь различать ситуации. Когда используется то или иное. В случае Абстрактной фабрики клиент использует методы фабрики для создания собственных объектов. В случае Строителя класс Строителя инструктируется о том. Как создать объект. А затем его просят об этом, но способ. Которым класс собирается вместе. Зависит от класса Строителя. И эта деталь делает разницу между двумя шаблонами.

Общий интерфейс для продуктов

На практике изделия. Созданные бетонщиками. Имеют существенно различную структуру. Поэтому если нет оснований выводить разные изделия из общего родительского класса.

Это также отличает шаблон Builder от абстрактного фабричного шаблона. Который создает объекты. Производные от общего типа.