Применимые случаи:
7.3 Применимые случаи для заводской модели
Самый простой способ создать новый объект - использовать новое ключевое слово и конкретные классы. Только в некоторых случаях дополнительная сложность создания и поддержания объектной фабрики стоит денег. Этот раздел суммирует эти случаи.
7.3.1 Динамическая реализация
Если вам нужно создавать объекты, которые реализуют один и тот же интерфейс по -разному, например, предыдущий пример велосипеда, вы можете использовать заводский метод или простой заводский объект, чтобы упростить процесс выбора реализации. Этот выбор может быть сделан явно или неявно. Первый похож на велосипедный пример, и клиент может выбрать велосипедную модель, которая вам нужна; в то время как пример фабрики XHR, упомянутый в следующем разделе, принадлежит последнему. Тип объекта подключения, возвращаемый в этом примере, зависит от обнаруженной пропускной способности и коэффициентов задержки сети. В этих ситуациях вам обычно приходится иметь дело с серией классов, которые реализуют один и тот же интерфейс и могут рассматриваться одинаково. Это наиболее распространенная причина использования заводской шаблона в JavaScript.
7.3.2 Сохранить настройки накладных расходов
Если объекты должны быть сложными и актуальными друг для друга, использование заводского режима может уменьшить количество кода, необходимого для каждого объекта. Этот эффект особенно заметен, если этот параметр должен быть выполнен только один раз для всех экземпляров конкретного типа. Поместить этот код настройки в конструктор класса не является эффективным подходом, потому что даже если настройка завершена, код все равно будет выполняться каждый раз, когда создается новый экземпляр, и это будет распространять код настройки в разные классы. Фабричный метод идеально подходит для этого случая. Это может быть установлено сразу, прежде чем создавать все необходимые объекты. Независимо от того, сколько разных классов создается, этот метод может сохранить код настройки в одном месте.
Это особенно полезно, если используемый класс требует загрузки внешней библиотеки. Заводские методы могут проверить эти библиотеки и динамически загружать те, которые не найдены. Эти коды настроек существуют только в одном месте, поэтому гораздо удобнее изменить их позже.
7.3.3 Сделайте большой объект со многими небольшими объектами
Метод завода может использоваться для создания объектов, которые инкапсулируют многие меньшие объекты. Рассмотрим конструктор велосипедного объекта. Велосипеды содержат много небольших подсистем: колеса, рамы, компоненты передачи и тормоза. Если вам не нужна сильная связь между подсистемой и большим объектом, но вы хотите выбрать из многих подсистем во время выполнения, то заводский подход является идеальным выбором. Используя эту технологию, вы можете однажды сопоставить все велосипеды, которые вы продаете с какой -то сетью, и если вы найдете еще одну более любимую сеть на следующий день, вместо этого вы можете использовать этот новый сорт. Это легко внедрить это изменение, потому что конструкторы этих велосипедных классов не зависят от конкретного сорта цепи. Пример считывателя RSS позже в этой главе демонстрирует использование заводской модели в этом отношении.
Заводской шаблон в основном обеспечивает интерфейс для создания объектов. Заводская модель разделена на три категории в соответствии с терминами «Java и Pattern»:
1. Простая фабрика
2. Заводский метод
3. Абстрактная фабрика
Эти три шаблона постепенно абстрактные сверху донизу и являются более общими. Существует также метод классификации, который состоит в том, чтобы рассматривать простую заводскую модель как особый случай модели фабричного метода, и они классифицируются в одной и той же категории. Вот две ситуации, когда используется заводский режим:
1. При кодировании вы не можете предвидеть, какие случаи вам нужно создать.
2. Система не должна полагаться на подробности о том, как создаются, объединены и выраженные экземпляры класса продукта
3. Простая заводская модель
Как следует из названия, сама эта модель проста и используется в ситуациях, когда бизнес проще.
Он состоит из трех ролей (см. Диаграмму классов ниже для отношений):
1. Фабрика: это ядро этой модели, которая содержит определенную бизнес -логику и логику суждения. В Java это часто реализуется конкретным классом.
2. Роль абстрактного продукта: обычно это родительский класс, унаследованный конкретным продуктом или реализованным интерфейсом. Реализовано интерфейсами или абстрактными классами в Java.
3. Конкретная роль продукта: объект, созданный заводским классом, является экземпляром этой роли. Реализовано конкретным классом в Java.
Так как использовать простую заводскую модель? Позвольте мне привести вам пример. Я думаю, что это намного проще понять, чем длинное теоретическое текстовое описание! Вот лечение для модерн Риш: P
После использования простой заводской модели, Nouveau Riche теперь нужно только сидеть в машине и сказать водителю: «вождение». Посмотрим, как это реализовано:
// Аннотация роль продукта Public Interface Car {public void Drive (); } // Роль конкретного продукта открытый класс Бенз реализует CAR {public void Drive () {System.out.println ("rival benz"); }} открытый класс BMW реализует CAR {public void Drive () {System.out.println ("Вождение BMW"); }}. Полем Полем (Я не буду писать Audi: P) // Роль класса заводского класса открытый драйвер класса {// фабричный метод // Обратите внимание, что возвращение типа является абстрактная роль продукта Public Static Car DriverCar (String S) бросает исключение {// Судья логика, верните определенную роль продукта в клиент, если (S.EqualsIgnoreCase («Benz»)) вернуть новый Benz (); иначе if (s.equalsignorecase ("bmw")) вернуть новый bmw (); ...... еще бросить новое исключение (); Полем Полем Полем // Добро пожаловать, что nouveau Riche появился ... открытый класс магнат {public static void main (string [] args) {try {// Скажите водителю, что я принимаю Mercedes-Benz Car Car = Driver.drivercar ("benz"); // Дайте команду: Drive (); Полем ПолемЕсли вы поместите все классы в один файл, не забывайте, что только один класс объявлен публично. Отношения между классами в программе следующие:
Это простая заводская модель. Вот преимущества:
Прежде всего, после использования простой заводской модели наша программа не «больна» и больше соответствует реальности; и клиент освобожден от ответственности за непосредственное создание объектов продукта, но отвечает только за «потребляющие» продукты (как это делает nouveau Riche).
Давайте проанализируем простую заводскую модель с принципа открытия и закрытия. Когда Nouveau Riche добавляет автомобиль, если он соответствует контракту, разработанному абстрактным продуктом, он может использоваться клиентом, если он уведомляется на фабрике. Таким образом, для части продукта он соответствует принципу открытия и закрытия - открытие для расширения и закрытия для модификации; Но заводская часть кажется не идеальной, потому что каждый раз, когда добавляется автомобиль, соответствующая бизнес -логика и логика суждения должны быть добавлены в класс заводов, что, естественно, нарушает принцип открытия и закрытия.
Для такого фабричного класса (в нашем случае для водителя) мы называем его всемогущим классом или классом Бога.
Пример, который мы приводим, является самым простым случаем, и в практических приложениях вполне вероятно, что продукт является многоуровневой структурой дерева. Поскольку в простой фабричной модели есть только один заводский класс, чтобы соответствовать этим продуктам, это может разрушить наш класс Бога и, в свою очередь, исчерпать наших прекрасных программистов :(
Как я упоминал ранее, простая заводская модель подходит для ситуаций, когда бизнес будет простым. Но это может быть не очень адаптируемым к сложной бизнес -средам. Это должно быть сделано моделью метода фабрики! !
4. Модель фабричного метода
Давайте сначала посмотрим на его композицию:
1. Абстрактная заводская роль: это ядро заводского метода, она не имеет ничего общего с приложением. Это интерфейс, который должен реализовать конкретную заводскую роль, или родительский класс, который должен быть унаследован. В Java он реализован абстрактными классами или интерфейсами.
2. Конкретная заводская роль: он содержит код, связанный с конкретной бизнес -логикой. Вызвано приложением для создания соответствующего конкретного объекта продукта. В Java это реализовано бетонными классами.
3. Роль абстрактного продукта: это родительский класс, унаследованный конкретным продуктом или реализованным интерфейсом. В Java, как правило, есть абстрактные классы или интерфейсы для их реализации.
4. Конкретная роль продукта: объект, созданный конкретной заводской ролью, является примером этой роли. Реализовано конкретными классами в Java.
Используйте диаграммы классов, чтобы четко представлять отношения между ними:
Давайте используем полный пример, чтобы увидеть, как координируются различные роли в заводской модели. Говоря о бизнесе Nouveau Riche, тем больше и больше автомобилей они любят. Это заставило водителя страдать. Он должен был помнить и сохранить любую машину, и ему пришлось его использовать! Таким образом, модерный Риш сочувствовал ему и сказал: это зависит от ваших лет со мной, вам не придется так усердно работать в будущем. Я назначу вам нескольких сотрудников, просто позаботьтесь о них! Следовательно, появилось управление моделью метода фабрики. Код заключается в следующем:
// Абстрактные роли продукта, конкретные роли продукта похожи на простую заводскую модель, но они стали немного сложнее, вот немного опущено. // Абстрактная фабрика роли общественного интерфейса {public Car DriverCar (); } открытый класс BenzDriver реализует драйвер {public Car DriverCar () {return new benz (); }} открытый класс Bmwdriver реализует Driver {public Car DriverCar () {return new bmw (); }} ...... // Он должен сформировать соответствующие отношения с конкретным продуктом, здесь ... // Спросить г -н Нуво. Car Car = river.drivercar (); car.drive (); } catch (Exception e) {}}}Метод завода использует абстрактную заводскую роль в качестве ядра вместо использования конкретных классов в качестве ядра в простой заводской шаблоне. Давайте посмотрим на то, что принесла нам модель метода фабрики? Используйте принцип открытия и закрытия, чтобы проанализировать модель фабричного метода. Когда создается новый продукт (то есть автомобиль Nouveau Riche), если он генерируется в соответствии с договором, предоставленным роли абстрактного продукта и роли абстрактного завода, он может использоваться клиентом без необходимости изменять какой -либо существующий код. Похоже, что модель метода заводского метода полностью соответствует принципу открытия и закрытия!
Использование модели заводского подхода достаточно, чтобы справиться с большинством потребностей бизнеса, с которыми мы можем столкнуться. Однако, когда есть много типов продуктов, появится большое количество соответствующих заводских категорий, что не должно быть тем, что мы надеемся. Поэтому я предлагаю использовать простой заводской шаблон в этом случае в сочетании с заводским методом, чтобы уменьшить заводский класс: то есть, используя простой заводской шаблон для аналогичных видов на дереве продукта (обычно те, которые являются братьями в листьях дерева).
Конечно, с особыми обстоятельствами необходимо лечить с помощью особого лечения: для различных деревьев продуктов в системе, и на деревьях продуктов есть семейства продуктов, а затем в этом случае можно использовать абстрактную заводскую модель.
5. Резюме
Давайте посмотрим на вдохновение, данное простой заводской моделью и моделью фабричного метода:
Если мы не используем заводской шаблон для реализации нашего примера, возможно, код будет намного меньше - просто реализуйте существующий автомобиль, не используя полиморфизм. Но с точки зрения обслуживания, масштабируемость очень плохая (вы можете представить, что класс, который вы хотите коснуться после добавления автомобиля). Поэтому для улучшения масштабируемости и обслуживания стоит написать больше кода.
6. Абстрактная заводская шаблон
Давайте сначала поймем, что такое семейство продуктов: семейство продуктов, состоящих из функций, которые расположены в различных иерархиях продуктов и структурах. Если вы сможете четко понять эту концепцию, просто прочитав это предложение, я должен восхищаться вами. Давайте используем пример, чтобы проиллюстрировать его ярко.
BMWCAR и Benzcar на рисунке представляют собой два деревья продукта (иерархия продукта); в то время как BenzSportScar и BMWSportScar, как показано на рисунке, являются одним из семейств продуктов. Все они могут быть размещены в семье спортивных автомобилей, поэтому функции связаны. Точно так же BMWBussenseCar и BenzSportScar также являются тем же семейством продуктов.
Возвращаясь к теме абстрактной модели продукта, можно сказать, что разница между ИТ и моделью метода завода заключается в сложности необходимости создания объектов. Более того, абстрактная заводская модель является наиболее абстрактной и общей среди трех. Цель абстрактной заводской шаблона состоит в том, чтобы предоставить клиенту интерфейс для создания объектов продукта в нескольких семействах продуктов. Кроме того, следующие условия должны быть выполнены при использовании абстрактной заводской шаблона:
1. В системе есть несколько семейств продуктов, и система может потреблять только один из продуктов одновременно.
2. Используйте продукты, принадлежащие к тому же семейству продуктов.
Давайте посмотрим на различные роли абстрактного заводского образца (как точно так же, как и фабричный метод):
Роль абстрактной фабрики: это ядро заводского метода, она не имеет ничего общего с приложением. Это интерфейс, который должен реализовать конкретную заводскую роль, или родительский класс, который должен быть унаследован. В Java он реализован абстрактными классами или интерфейсами.
Конкретная заводская роль: он содержит код, связанный с конкретной бизнес -логикой. Вызвано приложением для создания соответствующего конкретного объекта продукта. В Java это реализовано бетонными классами.
Роль абстрактного продукта: это родительский класс или интерфейс реализации конкретного наследования продукта. В Java, как правило, есть абстрактные классы или интерфейсы для их реализации.
Конкретная роль продукта: объект, созданный конкретной заводской ролью, является примером этой роли. Реализовано конкретными классами в Java.
Прочитав первые два режима, я должен иметь четкое представление о координации между различными персонажами в этом режиме, поэтому я не буду придавать конкретные примеры. Просто вы должны обратить внимание на удовлетворение условий для использования абстрактной заводской модели, в противном случае, даже если есть несколько деревьев продукта, все еще есть семьи продуктов, но их нельзя использовать.
Приведенная выше статья имеет глубокое понимание трех заводских моделей Java. Это весь контент, которым я делюсь с вами. Я надеюсь, что вы можете дать вам ссылку, и я надеюсь, что вы сможете поддержать Wulin.com больше.