Паттерн проектування методу заводу - це a креативний шаблон дизайну який забезпечує інтерфейс для створення об’єктів у суперкласі, дозволяючи підкласам змінювати тип об’єктів, які будуть створюватися. Він інкапсулює логіку створення об’єкта в окремому методі, сприяючи слабкому зв’язку між творцем і створеними об’єктами. Цей шаблон особливо корисний, коли точні типи об’єктів, які потрібно створити, можуть змінюватися або їх потрібно визначати під час виконання, що забезпечує гнучкість і розширюваність у створенні об’єктів.
Зміст
- Що таке шаблон проектування методу заводу?
- Коли використовувати шаблон проектування фабричного методу?
- Компоненти шаблону проектування методу заводу
- Приклад шаблону проектування фабричного методу
- Випадки використання шаблону проектування методу Factory
- Переваги шаблону проектування фабричного методу
- Недоліки шаблону проектування фабричного методу
Що таке шаблон проектування методу заводу?
Шаблон проектування методу Factory — це шаблон проектування, який використовується в розробці програмного забезпечення для надання інтерфейсу для створення об’єктів у суперкласі, дозволяючи підкласам змінювати тип об’єктів, які будуть створюватися. Він інкапсулює логіку створення об’єкта в окремому методі, абстрагуючи процес створення екземплярів і сприяючи слабкому зв’язку між творцем і створеними об’єктами. Цей шаблон забезпечує гнучкість, розширюваність і зручність обслуговування в кодовій базі, дозволяючи підкласам визначати власну реалізацію фабричного методу для створення конкретних типів об’єктів.
як ініціалізувати масив у java
Коли використовувати шаблон проектування фабричного методу?
Використовуйте фабричний шаблон дизайну:
- Якщо ви хочете інкапсулювати створення об’єкта: Якщо у вас є складний процес створення об’єкта або якщо процес може змінюватися залежно від умов, інкапсуляція цієї логіки у фабричний метод може спростити код клієнта та сприяти повторному використанню.
- Якщо ви хочете відокремити клієнтський код від конкретних класів: Використання шаблону методу Factory дозволяє вам створювати об’єкти через інтерфейс або абстрактний клас, абстрагуючись від конкретних деталей реалізації конкретних класів із коду клієнта. Це сприяє слабкому зв’язку та полегшує модифікацію або розширення системи без впливу на існуючий код клієнта.
- Якщо вам потрібно підтримувати кілька варіантів продукту: Якщо вашій програмі потрібно створити різні варіанти продукту або якщо в майбутньому можуть бути представлені нові типи продуктів, шаблон методу фабрики забезпечує гнучкий спосіб пристосування до цих варіацій, визначаючи методи фабрики для кожного типу продукту.
- Якщо ви хочете підтримувати налаштування або конфігурацію: Фабрики можна використовувати для інкапсуляції логіки конфігурації, що дозволяє клієнтам налаштовувати процес створення, надаючи параметри або параметри конфігурації методу фабрики.
Компоненти шаблону проектування методу заводу
1. Творець
Це абстрактний клас або інтерфейс, який оголошує фабричний метод. Творець зазвичай містить метод, який служить фабрикою для створення об’єктів. Він також може містити інші методи, які працюють зі створеними об'єктами.
2. Конкретний творець
Класи Concrete Creator — це підкласи Creator, які реалізують фабричний метод для створення конкретних типів об’єктів. Кожен Concrete Creator відповідає за створення конкретного продукту.
3. Продукт
Це інтерфейс або абстрактний клас для об’єктів, які створює метод фабрики. Продукт визначає спільний інтерфейс для всіх об’єктів, які може створити фабричний метод.
шилпа шетті вік
4. Бетонні вироби
Класи Concrete Product — це фактичні об’єкти, які створює метод фабрики. Кожен клас Concrete Product реалізує інтерфейс Product або розширює абстрактний клас Product.
Приклад шаблону проектування фабричного методу
Нижче наведено формулювання проблеми для розуміння шаблону проектування методу фабрики:
Розглянемо прикладну програму, яка повинна обробляти створення різних типів транспортних засобів, таких як двоколісні, триколісні та чотириколісні. Кожен тип транспортного засобу має свої особливості та поведінку.
1. Без шаблону проектування методу заводу
Java /*package whatever //do not write package name here */ import java.io.*; // Library classes abstract class Vehicle { public abstract void printVehicle(); } class TwoWheeler extends Vehicle { public void printVehicle() { System.out.println('I am two wheeler'); } } class FourWheeler extends Vehicle { public void printVehicle() { System.out.println('I am four wheeler'); } } // Client (or user) class class Client { private Vehicle pVehicle; public Client(int type) { if (type == 1) { pVehicle = new TwoWheeler(); } else if (type == 2) { pVehicle = new FourWheeler(); } else { pVehicle = null; } } public void cleanup() { if (pVehicle != null) { pVehicle = null; } } public Vehicle getVehicle() { return pVehicle; } } // Driver program public class GFG { public static void main(String[] args) { Client pClient = new Client(1); Vehicle pVehicle = pClient.getVehicle(); if (pVehicle != null) { pVehicle.printVehicle(); } pClient.cleanup(); } }> Вихід I am two wheeler>
Які проблеми з вищезазначеним дизайном?
У наведеному вище дизайні коду:
- Жорстке зчеплення: Клас клієнта
Client>безпосередньо створює конкретні класи (TwoWheeler>іFourWheeler>) на основі типу введення, наданого під час його побудови. Це призводить до тісного зв’язку між клієнтом і конкретними класами, що ускладнює підтримку та розширення коду. - Порушення принципу єдиної відповідальності (SRP): The
Client>клас відповідає не лише за визначення типу транспортного засобу, який потрібно створити на основі типу вхідних даних, але й за керування життєвим циклом об’єкта транспортного засобу (наприклад, очищення). Це порушує принцип єдиної відповідальності, який стверджує, що клас повинен мати лише одну причину для зміни. - Обмежена масштабованість: Додавання нового типу транспортного засобу вимагає модифікації
Client>класу, який порушує принцип «відкрито-закрито». Цей дизайн не можна масштабувати, оскільки він не може вмістити нові типи транспортних засобів без зміни існуючого коду.
Як нам уникнути проблеми?
- Визначити заводський інтерфейс: Створити
VehicleFactory>інтерфейс або абстрактний клас із методом створення транспортних засобів. - Реалізація бетонних заводів: Впровадити класи бетонного заводу (
TwoWheelerFactory>іFourWheelerFactory>), які реалізуютьVehicleFactory>інтерфейс і надають методи для створення екземплярів конкретних типів транспортних засобів. - Рефакторинг клієнта: Змінити
Client>клас прийняти aVehicleFactory>екземпляр замість безпосереднього створення транспортних засобів. Клієнт запитує транспортний засіб із заводу, усуваючи потребу в умовній логіці на основі типів транспортних засобів. - Покращена гнучкість: За допомогою цього підходу додавати нові типи транспортних засобів так само просто, як створити новий заводський клас для нового типу транспортного засобу без зміни існуючого клієнтського коду.
2. З шаблоном дизайну заводського методу
Давайте розберемо код на компоненти:
1. Інтерфейс продукту
Java // Product interface representing a vehicle public abstract class Vehicle { public abstract void printVehicle(); }> 2. Вироби з бетону
Java // Concrete product classes representing different types of vehicles public class TwoWheeler extends Vehicle { public void printVehicle() { System.out.println('I am two wheeler'); } } public class FourWheeler extends Vehicle { public void printVehicle() { System.out.println('I am four wheeler'); } }> 3. Інтерфейс творця (заводський інтерфейс)
Java // Factory interface defining the factory method public interface VehicleFactory { Vehicle createVehicle(); }> 4. Concrete Creators (Бетонні заводи)
Java // Concrete factory class for TwoWheeler public class TwoWheelerFactory implements VehicleFactory { public Vehicle createVehicle() { return new TwoWheeler(); } } // Concrete factory class for FourWheeler public class FourWheelerFactory implements VehicleFactory { public Vehicle createVehicle() { return new FourWheeler(); } }> Повний код цього прикладу:
Java // Library classes abstract class Vehicle { public abstract void printVehicle(); } class TwoWheeler extends Vehicle { public void printVehicle() { System.out.println('I am two wheeler'); } } class FourWheeler extends Vehicle { public void printVehicle() { System.out.println('I am four wheeler'); } } // Factory Interface interface VehicleFactory { Vehicle createVehicle(); } // Concrete Factory for TwoWheeler class TwoWheelerFactory implements VehicleFactory { public Vehicle createVehicle() { return new TwoWheeler(); } } // Concrete Factory for FourWheeler class FourWheelerFactory implements VehicleFactory { public Vehicle createVehicle() { return new FourWheeler(); } } // Client class class Client { private Vehicle pVehicle; public Client(VehicleFactory factory) { pVehicle = factory.createVehicle(); } public Vehicle getVehicle() { return pVehicle; } } // Driver program public class GFG { public static void main(String[] args) { VehicleFactory twoWheelerFactory = new TwoWheelerFactory(); Client twoWheelerClient = new Client(twoWheelerFactory); Vehicle twoWheeler = twoWheelerClient.getVehicle(); twoWheeler.printVehicle(); VehicleFactory fourWheelerFactory = new FourWheelerFactory(); Client fourWheelerClient = new Client(fourWheelerFactory); Vehicle fourWheeler = fourWheelerClient.getVehicle(); fourWheeler.printVehicle(); } }> Вихід I am two wheeler I am four wheeler>
У наведеному вище коді:
кінцевий автомат
-
Vehicle>служить інтерфейсом продукту, що визначає загальний методprintVehicle()>які повинні виконувати всі бетонні вироби. -
TwoWheeler>іFourWheeler>- це конкретні класи продуктів, що представляють різні типи транспортних засобів, реалізуючиprintVehicle()>метод. -
VehicleFactory>діє як інтерфейс Creator (Factory Interface) з методомcreateVehicle()>представляє заводський метод. -
TwoWheelerFactory>іFourWheelerFactory>це конкретні класи творців (Бетонні заводи), які реалізуютьVehicleFactory>інтерфейс для створення екземплярів конкретних типів транспортних засобів.
Випадки використання шаблону проектування методу Factory
Ось кілька поширених застосувань шаблону Factory Method Design:
- Креативні рамки:
- JDBC (Java Database Connectivity) широко використовує фабрики для створення з’єднань, операторів і наборів результатів. Фреймворки впровадження залежностей, такі як Spring і Guice, значною мірою покладаються на фабрики для створення компонентів і керування ними.
- Набори інструментів GUI:
- Swing і JavaFX використовують фабрики для створення компонентів інтерфейсу користувача, таких як кнопки, текстові поля та мітки, що забезпечує налаштування та гнучкість дизайну інтерфейсу користувача.
- Рамки журналювання:
- Такі фреймворки журналювання, як Log4j і Logback, використовують фабрики для створення логгерів із різними конфігураціями, що дозволяє контролювати рівні журналювання та призначення виводу.
- Серіалізація та десеріалізація:
- Фреймворки серіалізації об’єктів часто використовують фабрики для створення об’єктів із серіалізованих даних, підтримуючи різні формати серіалізації та версії.
- Системи плагінів:
- Системи на основі плагінів часто використовують фабрики для динамічного завантаження та створення екземплярів плагінів, що дозволяє розширювати та налаштовувати.
- Розробка гри:
- Ігрові движки часто використовують фабрики для створення різних типів ігрових об’єктів, персонажів і рівнів, сприяючи організації та гнучкості коду.
- Веб-розробка:
- Веб-фреймворки іноді використовують фабрики для створення компонентів перегляду, контролерів і служб, що забезпечує модульність і можливість тестування веб-додатків.
Переваги шаблону проектування фабричного методу
Переваги Factory Method Design Pattern:
вибрати з кількох таблиць sql
- Роз'єднання: Він відокремлює логіку створення об’єктів від клієнтського коду, який використовує ці об’єкти. Це робить код більш гнучким і придатним для обслуговування, оскільки зміни в процесі створення не вимагають змін коду клієнта.
- Розширюваність: Легко представити нові типи продуктів, не змінюючи код клієнта. Вам просто потрібно створити новий підклас Concrete Creator і реалізувати заводський метод для створення нового продукту.
- Тестування: Це спрощує модульне тестування, дозволяючи імітувати або заглушати створення продукту під час тестування. Ви можете тестувати різні реалізації продукту окремо, не покладаючись на фактичне створення об’єкта.
- Повторне використання коду: Фабричний метод можна повторно використовувати в різних частинах програми, де потрібно створити об’єкт. Це сприяє централізації та повторному використанню логіки створення об’єктів.
- Інкапсуляція: Він приховує конкретні класи продуктів від коду клієнта, роблячи код менш залежним від конкретних реалізацій. Це покращує ремонтопридатність і зменшує зчеплення.
Недоліки шаблону проектування фабричного методу
Недоліками Factory Method Design Pattern є:
- Підвищена складність: Він представляє додаткові класи та інтерфейси, додаючи рівень абстракції, який може зробити код більш складним для розуміння та підтримки, особливо для тих, хто не знайомий із шаблоном.
- Накладні витрати: Використання поліморфізму та динамічного зв’язування може незначно вплинути на продуктивність, хоча це часто незначно в більшості програм.
- Тісний зв’язок в ієрархії продуктів: Творці бетону все ще тісно пов’язані зі своїми відповідними продуктами Concrete. Зміни в одному часто вимагають змін в іншому.
- Залежність від конкретних підкласів: Клієнтський код все ще залежить від абстрактного класу Creator, вимагаючи знання його конкретних підкласів для правильного виклику фабричних методів.
- Можливість надмірного використання: Важливо розумно використовувати шаблон Factory Method, щоб уникнути надмірної розробки програми. Створення простого об’єкта часто можна виконати безпосередньо, не потребуючи фабрики.
- Проблеми тестування: Тестування самої заводської логіки може бути складнішим.