Как понимать фабричный класс в классе фабричный метод??
Пытаюсь разобраться в фабричном паттерне, не очень могу понять зачем нужен Factory.
Смотрю пример с этого сайта. Какой там смысл класса "ParserFactory", если можно избавившись от класса просто тоже самое написать в методе??
Евгений Шатунов, @back, на примере который на сайте, там присутствует класс "ParserFactory", если реализацию методов класса перенести в класс "AbstractFactoryTest". Без создания самого класса Factory. То это останется фабричным методом? или класс "ParserFactory" является основным
artshelom , сайт ты себе выбрал прям таки как эталон обучающей системы. 30 слов в предложении и ничего не понятно. Потрясающее умение!
Описание в "назначении" шаблона фабрики на этом сайте не описывает ничего. Особенно фабрику.
Более того, примеры бестолковые. Они поясняют только то, как не надо использовать порождающие шаблоны. Вот как там в примерах показано, так и не надо делать.
Можно всю программу зафигачить в одной функции и при этом единственная функция будет выполнять все требующееся от программы. Зачем нам вообще эти шаблоны дались?
В тот момент, когда тебе потребуется расширить функциональность уже долгое время стабильно работающего кода (~2MB текста), с каким кодом тебе будет удобнее работать? С кодом, в котором все свалено в одну большую кучу и который надо переписывать целиком при каждой доработке? Или с кодом, в котором есть элементы абстракции, работающие как точки возможного расширения функционала, и где для расширения функциональности достаточно просто внедрить новые элементы конкретики для абстракции?
Касательно самой фабрики и фабричных методов нужно сразу уяснить себе два важных момента.
Момент первый. Фабричный метод производит объекты только одного конкретного типа в безусловном режиме. Фабричный метод нужен как абстракция над процессом создания объекта.
Все фабричные методы для одного семейства классов всегда имеют единую сигнатуру и всегда могут использоваться без знания конкретных классов семейства.
Часто, почти всегда, конкретный фабричный метод семейства выполняется как статическая функция конкретного класса этого семейства.
Ключевым моментом фабричного метода является то, что для любого семейства классов, для которых созданы фабричные методы, имея на руках набор аргументов и абстрактный фабричный метод, вызвав метод с передачей аргументов ты получишь объект с общим интерфейсом этого семейства.
Момент второй. Абстрактная фабрика - это просто агрегатор фабричных методов. Абстрактная фабрика связывает конкретный фабричный метод с неким состоянием конструкции, которое часто выражается в виде еще одного параметра.
Абстрактная фабрика - это буквально ассоциативный массив из состояние => фабричный метод. Само собой понятно что это объект некоторого класса, а не сам класс. Это важно понимать.
Т.к. сигнатуры всех фабричных методов в рамках одного семейства одинаковы, абстрактная фабрика легко складывает их в ассоциацию. Саму же ассоциацию устанавливает только сам программист, регистрируя фабричные методы в фабрике и ассоциируя их с неким состоянием.
И вот где здесь точка абстракции.
Пользователь фабрики никак не обременен знанием конкретики семейства, экземпляры классов которого создает фабрика. Тип фабрики реализован так, что его, по факту, можно использовать и для другого семейства со схожими условиями конструкции. Прикладные типы семейства предельно конкретны и реализуют строго свои функции, не распыляясь на код менеджмента того или иного шаблона.
И самое главное - благодаря регистрации методов в фабрике, ее расширяемость перестает зависеть от ее кода. Регистрировать новые классы можно и в других подсистемах, в других слоях, далеко за пределами текущей подсистемы и текущего слоя архитектуры.
И, без сомнения, книга, которую я посоветую читать в первую очередь. Дастин Боссуэлл, "Читаемый код, или Программирование как искусство". Книга изобилует примерами на C++, но не относится к области плюсов. Книгу важно изучить буквально всем людям, чье понимание написания кода еще не сформировалось. И тем более ее важно прочитать тем, чье понимание уже сформировано, для коррекции понимания.
Но ни что не сделает для тебя понимание подходов более понятным, чем регулярная практика. Нужно всегда задавать себе вопрос: удобно ли пользоваться кодом, что я сейчас пишу?
Чтобы потом проще программировать было. Без вникания в то, что находится за интерфейсом. Все по полочкам, предсказуемо структурировано и предсказуемо себя ведет.
Давным-давно я думал, что ООП и паттерны вообще актуальны только "для больших проектов". Когда я перестал так думать - стал разрабатывать раз в 5 быстрее.
Ну если делать без этого класса. Это ведь всё же останется фабричным методом??
или кто-то может начать выпендриваться и говорить, что без этого класса не работает?
artshelom, не помню, когда "на ты" перешли, но тем не менее посоветую:
- agile
- github, открытые проекты
- rapid development
- вообще основы программирования, классная штука
Торкнет тогда, когда перейдете на СПО, начнете пользоваться и обнаружите явные недоработки. Их там много, не меньше чем в проприетарщине, но на этот раз вы можете на что-то повлиять.
Имею в виду, работайте над чем-то близким и понятным. Примите мысль, что вне зависимости от вашей фактической квалификации вы можете быть ОЧЕНЬ полезным прямо здесь и сейчас. В течение следующих 2-3 часов вы можете толкнуть вперед научный прогресс и сделать много полезного. Не шучу.