Показаны сообщения с ярлыком Abstract Factory. Показать все сообщения
Показаны сообщения с ярлыком Abstract Factory. Показать все сообщения

суббота, 19 июля 2025 г.

Abstract Factory, Factory Method, Example

Abstract Factory VERSUS Factory Method
---

D:\VC25\Otus\Py\projects\des_patterns\2_abstract_factory

Паттерны «Фабричный метод» и «Абстрактная фабрика» — это два похожих, но отличающихся подхода к созданию объектов.

Оба паттерна решают проблему создания объектов, но решают её разными способами и преследуют разные цели.

Основные различия:

1. Уровень абстракции

  • Фабричный метод:
  • создает единичные объекты определенного типа.
  • Он определяет метод создания объекта, но оставляет решение о том, какой именно объект создать, конкретным подклассам.
  • Абстрактная фабрика:
  • создает целые семейства объектов, которые зависят друг от друга и принадлежат одной тематике.
  • Она не просто создает один объект,
  • а формирует набор объектов, согласованных между собой.

2. Гибкость и расширение

  • Фабричный метод: обеспечивает свободу в выборе конкретного типа объекта, который нужно создать.
  • Например, можно создать разные виды автомобилей, используя один и тот же метод фабрики.
  • Абстрактная фабрика: предоставляет возможность создавать несколько взаимосвязанных объектов сразу.
  • Это позволяет создавать целостные комплексы объектов, которые поддерживают общее семантическое соглашение
  • (например, набор UI-элементов, принадлежащих одной теме оформления).

3. Способ задания зависимости

  • Фабричный метод:
  • вызывает фабричный метод непосредственно в клиентском коде, а подклассы выбирают конкретный объект для создания.
  • Абстрактная фабрика:
  • использует абстрактный интерфейс для создания набора объектов,
  • а конкретные фабрики предоставляют реализации для создания конкретных наборов объектов.

4. Степень контроля над созданием объектов

  • Фабричный метод:
  • дает контроль над созданием одного объекта за раз.
  • Абстрактная фабрика:
  • дает контроль над созданием целой группы объектов одновременно.

Пример сравнения:

Ситуация 1: Выбор автомобиля

  • Фабричный метод:
  • фабрика производит автомобили разных марок (BMW, Mercedes, Tesla).
  • Клиент вызывает фабричный метод и получает машину желаемого бренда.
  • Абстрактная фабрика:
  • фабрика производит комплектацию автомобиля (корпус, мотор, колеса).
  • Каждая фабрика отвечает за производство полной комплектации машины (спортивная машина, внедорожник, седан),
  • включающей согласованные между собой комплектующие.

Ситуация 2: Создание графического интерфейса

  • Фабричный метод:
  • фабрика создает кнопки, выпадающие списки, текстовые поля и другие элементы интерфейса.
  • При этом клиент сам выбирает, какой элемент создать.
  • Абстрактная фабрика:
  • фабрика создает целый набор элементов интерфейса (кнопки, чекбоксы, текстовые поля),
  • принадлежащий одной теме оформления (например, "тёмная тема" или "светлая тема").
  • Фабрики специализируются на создании наборов элементов, подходящих друг к другу по стилю.

В итоге:

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

Выбор паттерна зависит от того, насколько сложной и обширной должна быть система создания объектов.

Abstract Factory, Example, Giga, Path

Abstract Factory, Example, Giga, Path

https://refactoring.guru/ru/design-patterns/abstract-factory

https://giga.chat/link/gcsUUyXJCB

D:\VC25\Otus\Py\projects\des_patterns\2_abstarct_factory

Цели нашего примера:

Мы решили продемонстрировать,

как паттерн «Абстрактная фабрика» позволяет создавать целостные наборы объектов,

относящихся к определенной тематике (семейству), и гарантирует,

что объекты из одного семейства соответствуют друг другу.

Задача:

Нам нужно создать интерфейс (UI),

который поддерживает две темы оформления: светлую и тёмную.

Наша задача — спроектировать такую систему, чтобы можно было легко переключаться между темами,

при этом сохранив логичность и консистентность каждого элемента (например, кнопка, чекбокс и текстовое поле) в рамках выбранной темы.

Как мы подошли к решению:

Мы использовали паттерн «Абстрактная фабрика», потому что:

  • Нам нужно создавать целые наборы элементов интерфейса, а не единичные объекты.
  • Важно, чтобы элементы из одного набора соответствовали друг другу визуально и стилистически.
  • Должна быть возможность легко переключаться между наборами (темами), без необходимости изменять клиентский код.

Какие этапы мы выполнили:

  1. Определение абстрактных интерфейсов:
    • Мы определили абстрактный класс для UI-элементов (AbstractUIElement),
    • который обязывает все реальные элементы интерфейса (кнопки, чекбоксы,
    • текстовые поля) реализовать метод render.
    • Также мы определили абстрактную фабрику (AbstractUIFactory), которая обязана создавать полный набор элементов (кнопку,
    • чекбокс и текстовое поле).
  2. Создание конкретных реализаций:
    • Далее мы создали конкретные классы элементов интерфейса для каждой темы (светлые и темные версии).
    • Затем мы разработали конкретные фабрики (LightUIFactory и DarkUIFactory), каждая из которых способна создать набор элементов,
    • соответствующий своей теме.
  3. Организация взаимодействия:
    • Наш клиентский код (функция ui_elements_demo) принимает любую фабрику и вызывает методы фабрики для создания элементов.
    • По сути, клиентский код не знает, какую именно тему он получит — он просто просит у фабрики создать элементы и вызывает их методы.

Что получилось в результате:

  1. Модульность и расширение:
    • Весь код аккуратно разделён на части, и любая дополнительная тема (например,
    • третья — красная тема или зелёная) может быть легко добавлена путём создания новой фабрики и новых классов элементов.
  2. Независимость от конкретного типа:
    • Нет никакой зависимости между элементами одной темы и клиентским кодом.
    • Переключиться на другую тему можно просто сменив фабрику.
  3. Корректность взаимодействия:
    • Элементы из одного семейства гарантированно сочетаются друг с другом.
    • Нельзя случайно смешать светлые и тёмные элементы,
    • так как каждая фабрика создаёт однородный набор.

Итоговый вывод:

Наш пример наглядно показал,

как паттерн «Абстрактная фабрика» позволяет создавать целостные наборы объектов,

организованных по общему признаку (тема оформления).

Благодаря такому подходу наше приложение стало легко настраиваемым и расширяемым,

позволяя добавлять новые темы без изменения существующего кода.

  • Проверка правильность размещения файлов и отсутствие конфликтов имен.
  • Можно развить идею, добавив третью тему или новый тип элемента интерфейса.
  • Расширении функциональных возможностей элементов (например, добавить анимацию, интерактивность).

Abstract Factory

Abstract Factory, Giga, Path

https://refactoring.guru/ru/design-patterns/abstract-factory

https://giga.chat/link/gcsUUyXJCB

D:\VC25\Otus\Py\projects\des_patterns\2_abstarct_factory

Абстрактная фабрика — это порождающий паттерн проектирования, который позволяет создавать семейства связанных объектов, не привязываясь к конкретным классам создаваемых объектов.

1. Суть паттерна

Паттерн «Абстрактная фабрика» — это порождающий шаблон проектирования,

который предоставляет интерфейс для создания целых семейств связанных или зависящих друг от друга объектов,

не специфицируя их конкретные классы.

Другими словами,

он позволяет создавать наборы родственных объектов, придерживаясь единого подхода к созданию,

но при этом оставаясь гибким к появлению новых вариантов семейств.

Главная цель паттерна — отделение процесса создания семейства объектов от их использования,

что позволяет легко менять целый набор объектов при сохранении общей логики программы.

2. Когда использовать?

Паттерн «Абстрактная фабрика» применяют в следующих случаях:

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

Паттерн «Абстрактная фабрика» стоит использовать в следующих ситуациях:

1. Когда нужно создать семейство взаимосвязанных объектов

Часто в программах возникают ситуации, когда объекты образуют целые группы или семейства, тесно связанные друг с другом.

Например, UI-интерфейс с темой оформления (светлая тема vs. тёмная тема),

драйверы для работы с разными типами оборудования (Windows vs. Linux),

сервисы интеграции с разными поставщиками услуг (Google Cloud Storage vs. Amazon S3).

В таких случаях создание каждого объекта индивидуально привело бы к сильному

увеличению сложности и сильно связано бы клиентский код с конкретными реализациями.

Паттерн «Абстрактная фабрика» позволяет свести это к минимуму,

предоставляя единую точку входа для создания всех необходимых объектов семейства.

2. Когда требуется сменить целую группу объектов без изменения клиентского кода

Одним из ключевых достоинств паттерна является возможность полного изменения семейства объектов без необходимости

переписывать существующий клиентский код.

Например, если в вашем приложении внезапно понадобится перейти с SQLite на PostgreSQL или сменить дизайн UI-интерфейса,

паттерн «Абстрактная фабрика» позволит легко это сделать,

поменяв всего лишь тип фабрики, который используется в программе.

3. Когда объекты связаны общим назначением, но различаются внешне

Если у вас есть группа объектов, которые выполняют сходные функции, но выглядят или

ведут себя иначе в зависимости от внешних факторов (операционной системы,

конфигурации среды, предпочтений пользователя и т.д.),

паттерн «Абстрактная фабрика» даст вам возможность группировать подобные объекты в логически обоснованные семейства.

Например, в графическом интерфейсе пользователь может видеть одинаковые элементы (полосы прокрутки, кнопки, таблицы),

но их внешний вид и поведение зависят от выбранной темы (OS X, Windows, Material Design и т.д.).

Каждая тема —

это отдельное семейство, и абстрактная фабрика позволит выбирать подходящую тему без вмешательства в логику программы.

4. Когда появляются потенциальные комбинации семейств объектов

По мере роста проекта разнообразие комбинаций типов объектов возрастает.

Например, при работе с драйверами устройств или интеграцией с различными провайдерами облачных сервисов,

у вас может появиться потребность создать разные сочетания драйверов и провайдеров

(например, Windows с Google Cloud, Linux с AWS).

Паттерн «Абстрактная фабрика» позволяет удобно формировать эти комбинации, предоставляя удобные фабрики для каждого случая.

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

Одной из сильных сторон паттерна «Абстрактная фабрика» является слабая связанность между клиентом и конкретными классами объектов.

Клиент взаимодействует только с абстрактной фабрикой, а значит,

любые изменения внутри семейств объектов останутся локальными и не коснутся клиентского кода.

Такой подход делает систему легко расширяемой:

добавление новых семейств объектов выполняется простым добавлением новой фабрики и соответствующей реализации объектов,

не затрагивая старый код.

Пример использования:

Допустим, у вас есть приложение, которое работает с несколькими видами документов (PDF, Word, Excel)

и вам нужно поддерживать печать документов в двух вариантах оформления (цветной и черно-белый).

В этом случае можно использовать абстрактную фабрику для создания семейств объектов печати:

  • Черно-белая фабрика: печатает PDF, Word и Excel в чёрно-белом режиме.
  • Цветная фабрика: печатает те же документы, но в цвете.

Таким образом, ваш клиентский код останется компактным и лаконичным,

и в будущем вы сможете легко добавить новые виды документов или способов печати, изменяя только фабрику.

Итог:

Паттерн «Абстрактная фабрика» идеален,

когда речь идет о создании целой группы взаимосвязанных объектов,

разделенных на логические семейства, и когда важен высокий уровень гибкости и легкости

в замене целых семейств объектов без существенных изменений в клиентском коде.