[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Design Patterns
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
twin
Ты продолжаешь разочаровывать. Не пытайся запутать тем, что рассматриваешь логику не с той стороны. Фабричный метод, это следствие. Начинать нужно с SimpleFactory
Цитата (Santehnick @ 1.09.2017 - 00:15)
Верно, фабричный метод используют тогда когда процесс создания объекта несколько сложнее, чем обычный вызов конструктора. Иначе в этом паттерне нет смысла.
Еще раз. Если нужен один объект, процесс создания которого сложнее, чем вызов конструктора, который может использовать другие объекты или пошаговую инициализацию свойств в процессе создания, используется "Строитель". Билдер. Builder. Фабрика потому и называется фабрикой, что призвана производить на свет множество однотипных объектов. Глупо строить фабрику молотков, если нужен всего один молоток. Глупо строить фабрику для производства телевизоров (хотя его создание достаточно сложно), если нужен один телевизор. И для производства штучных автомобилей глупо строить фабрику. В паттерне есть смысл только тогда, когда нужно упорядочить создание кучи объектов. Однотипных.

Вот фабрика может пользоваться билдерами, если логика такова, как ты описал, для:
Цитата (Santehnick @ 31.08.2017 - 10:25)
создания объекта автомобиля, который состоит из объекта двигателя, объекта руля, объекта колес и так далее, которые в свою очередь также могут быть составными.
Только не "ля", а "лей". Автомобилей.

Вот это ты верно описал:
Цитата
Видим, что это дальнейшее развитие идеи фабричного метода. Теперь клиенту нужен не один объект, а целое семейство объектов. Например клиенту нужны объекты графического интерфейса, такие как Button (кнопка), Window (окно) и так далее. Мы знаем, что в Linux, Mac OS и Windows все эти объекты присутствуют, но имеют разную реализацию. Мы создаем AbstactButton, LinuxButton, MacOSButton, ButtonWindows, AbstractWindow, LinuxWindow, MacOSWindow, WindowWindows и фабрики AbstractGUIFactory, LinuxGUIFactory, MacOSGUIFactory, WindowsGUIFactory с методами createButton и createWindow. Каждая из реализаций абстрактной фабрики создает свою конкретную кнопку и своё окно. Клиент работает с AbstractGUIFactory и ему без разницы, какая реализация фабрики придет ему на вход LinuxGUIFactory, MacOSGUIFactory или WindowsGUIFactory он будет правильно работать с любой, так как зависит от AbstractGUIFactory, а не от её конкретной реализации.
Но опять же только тогда, когда нужно много однотипных кнопок и окон. Это как с фашистами, чуть позже объясню, причем тут они. Но только вопрос был в другом. Я спросил не как это устроено, это и без тебя понятно. Вопрос был - где это грамотно применить в веб?

Теперь к фашистам. А именно к сути фабрики снизу-вверх, а не как у тебя - наоборот.

Допустим мы пишем игру. И нам нужны бойцы. Возьмем для простоты два типа. Автоматчик и пулеметчик. Они оба должны уметь
1. Ходить.
2. Бегать.
3. Ползать.
4. Копать окоп.

Для начала пишется класс "солдат", который умеет это все делать.

Следующим этапом солдату придается специфика. Автоматчику стрелять из автомата, пулеметчику - стрелять из пулемета. Для этого нужны объекты "автомат" и "пулемет". Чтобы солдаты начали выполнять свою работу, используется либо наследование (что уже моветон априори), либо паттерн "фасад", если нам нужна атака, где не нужны умения "ползать" и "копать окоп", либо билдер, который создаст нужного персонажа, инкапсулируя логику его создания, либо делегирование, либо декоратор, либо компановщик... выбирай на вкус. Но это все не фабрика.

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

В реальности это конечно не так, но если смотреть с точки зрения правильной архитектуры создания игры, бойцы должны иметь одинаковые возможности. Быть однотипными. А значит должны строиться по одной схеме. За это отвечает абстрактная фабрика. Ей плевать, фашисты получатся или русские. Её интересует только то, чтобы все они умели ходить, бегать, ползать и рыть окоп.

Просто советские должны кричать "За родину!", а фашисты - "Хайль Гитлер". Вот это уже следующий этап, конкретика. Либо конечная фабрика, либо новый слой абстрактных фабрик, либо фабричный метод, тут тоже на вкус и цвет все фломастеры разные.

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

В десктопе это все понятно, логично и правильно. В момент запуска игры мы создаем тысячу солдат (для масштаба smile.gif ), 900 автоматчиков к примеру и 100 пулеметчиков. И командира полка. И с другой стороны, столько же проклятых фашистов.

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

Пока идет атака одними силами, резерв мирно ждет. Я не рассматриваю тут пулы, для простоты понимания пусть будет так. Пул, это другая тема.

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

В веб всё не так. Суть веб - создание страниц. Если атака, то резерв пока не нужен вообще, он понадобится только на следующей странице. Глупо создавать всю тысячу, если используется половина. Все равно неиспользованные объекты погибнут после завершения генерации страницы.

А если как в рыцарские времена, исход сражения мог решиться поединком, солдаты не нужны вообще. Пусть командиры дерутся.

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

Всё тоже самое и для твоих кнопок и окон. В десктопе это интересно, но вопрос был не в том. Основное отличие фабрики от билдера в том, что билдер строит объект, а фабрика его просто создает. В десктопе понятно, мы можем обратиться к фабрике много раз, запрашивая разные объекты семейства. Потому что логика в билдер закладывается жестко, до компиляции, а фабрика может штамповать их "на лету". Фабрика помогает разруливать динамическое создание объектов в зависимости от хотелок клиента. Это понятно. Но в веб то программа отрабатывает за один проход и умирает. Так что билдеров и иже с ними вполне достаточно. У нас просто нет возможности добавить еще одну кнопку в момент генерации страницы, как бы ни хотелось использовать этот шикарный паттерн. smile.gif

И вот теперь еще раз вопрос. Когда и для чего в веб нужен паттерн "фабрика"? Всё, что ты описывал - создание сложного объекта, это не фабрика. И решается другими паттернами, больше для этого подходящими. Инстанцирование одного простого объекта с помощью фабрики - антипаттерн Accidental complexity. А куча однотипных объектов в веб не нужна вовсе. От этого только вред. Так для чего?

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

Свернутый текст
Могу высказать предположение. Этот паттерн описан у банды четырех в самых первых строках. Да и не сложен. А значит больше всех западает в память. И когда возникает вопрос, как у ТС, какие паттерны наиболее популярны и востребованы, все суют туда фабрики. Ну как... Раз он первый, значит кому то надо. smile.gif


_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.