Яка різниця між фабричними та стратегічними моделями?

Чи може хтось пояснити різницю між фабричними та стратегічними моделями?

Для мене обидва виглядають інакше, ніж додатковий заводський клас (які створюють об'єкт продукту у фабричних моделях)

Фабричний візерунок - це креативний візерунок. Стратегічна схема - це операційна схема. Іншим способом, для створення об'єктів певного типу використовується заводський візерунок. Шаблон стратегії - це використання для виконання певної операції (або набору операцій). У класичному прикладі фабрика може створювати різні типи тварин: Собака, Кішка, Тигр, тоді як стратегічна схема виконуватиме конкретні дії, наприклад, Переміщення; використовуючи стратегії Run, Walk або Lope.

Насправді їх можна використовувати разом. Наприклад, у вас може бути фабрика, яка створює ваші бізнес-об’єкти. Він може використовувати різні стратегії, засновані на середовищі стійкості. Якщо ваші дані зберігаються локально в XML, вона використовувала б одну стратегію. Якби дані були віддалені в іншій базі даних, вона використовувала б іншу.

Шаблон стратегії дозволяє поліморфно змінити поведінку класу.

Заводський зразок дозволяє інкапсулювати створення об'єктів.

Гері робить велике значення. Якщо ви використовуєте принцип кодування до абстракцій, а не до конкрементів, то багато зразків починають виглядати як варіанти на тему.

Просто для додання того, що сказав tvanfosson, багато моделей виглядають так само, як і реалізація. Тобто, ви багато створюєте інтерфейс, де, можливо, раніше у вашому коді цього не було, а потім створюєте купу реалізацій цього інтерфейсу. Різниця полягає в їх призначенні та способах їх використання.

• Фабричний (метод) візерунок.

Створюйте лише конкретні екземпляри. Різні аргументи можуть призводити до різних об'єктів. Це залежить від логіки тощо.

• Стратегія.

Інкапсулюйте алгоритм (кроки) для виконання дії. Таким чином, ви можете змінити стратегію і використовувати інший алгоритм.

Хоча обидва схожі на дуже схожі, мета є досить різною, одна мета - створити іншу - виконати дію.

Так. Якщо ваш заводський метод виправлений, ви можете мати його так:

 public Command getCommand( int operatingSystem ) { 
      switch( operatingSystem ) { 
           case UNIX    :
           case LINUX   : return new UnixCommand();
           case WINDOWS : return new WindowsCommand();
           case OSX     : return new OSXCommand();
       }
  }

Але припустимо, що ваша фабрика потребує більш досконалого або динамічного створення. Ви можете додати до заводського методу стратегію та змінити її без необхідності перекомпілювати, стратегія може змінюватися під час виконання.

Перш за все, слід зробити різницю між простою фабрикою та абстрактною фабрикою. Перший - це проста фабрика, де у вас є лише один клас, який виступає фабрикою для створення об'єктів, тоді як у другому ви підключаєтесь до заводського інтерфейсу (який визначає назви методів), а потім викликаєте різні заводи, які реалізують цей інтерфейс, який повинні мати різні реалізації одного і того ж методу на основі деяких критеріїв. Наприклад, у нас є інтерфейс ButtonCreationFactory, який реалізується двома фабриками: перший WindowsButtonCreationFactory (створює кнопки з Windows look and feel) та другий LinuxButtonCreationFactory (створює кнопки з Linux look and feel). Отже, обидві ці фабрики мають однаковий метод створення з різними реалізаціями (алгоритмами).

Наприклад, якщо ви хочете, щоб кнопки з виглядом та відчуттям Linux:

ButtonCreationFactory myFactory = new LinuxButtonCreationFactory();
Button button1 = myFactory.createButton(...);

або якщо ви хочете кнопки Windows

ButtonCreationFactory myFactory = new WindowsButtonCreationFactory();
Button button1 = myFactory.createButton(...);

Саме в цьому випадку це призводить до своєрідної структури стратегії, оскільки вона диференціює алгоритми певного створення. Однак він відрізняється від нього семантично тим, що використовується для створення ОБ'ЄКТУ, а не оперативних алгоритмів. Отже, в основному з абстрактними фабриками ви створюєте об'єкти, використовуючи різні стратегії, що робить його дуже схожим на модель стратегії. Однак AbstractFactory є творчим, поки стратегія працює. Виконуючи розумне виконання, вони призводять до того ж.

Фабрика (і FactoryMethod повернута заводом) :

1. Творчий візерунок
2. На підставі спадкування
3. Factory повертає заводський метод (інтерфейс), який, у свою чергу, повертає Concrete Object
4. Ви можете замінити нові конкретні об’єкти на інтерфейс, а клієнт (абонент) не повинен знати про всі конкретні реалізації
5. Клієнт завжди має доступ лише до інтерфейсу, і ви можете приховати деталі створення об’єктів у Фабричному методі

Подивіться цю статтю на вікіпедію та статтю, яку переглянули javarevisited

Шаблон стратегії:

1. Це поведінковий зразок
2. Він заснований на делегуванні
3. Він змінює кишки об'єкта, змінюючи поведінку методу
4. Він використовується для перемикання між сімейством алгоритмів
5. Це змінює поведінку об'єкта під час виконання

Приклад:

Ви можете налаштувати стратегію знижок для певного товару (квиток AirFare або пункт ShoppingCart). У цьому прикладі ви запропонуєте 25% знижку на товар протягом липня - грудня та відсутність знижки на товар під час Jaunary - червень.

Схожі повідомлення:

Приклад реального світу стратегії

Шаблони дизайну: Фабрика проти заводського методу проти абстрактного заводу

Щоб продовжити те, що сказав Оскар та посилаючись на його код:

GetCommand - це завод, а UnixCommand, WindowsCommand та OSXCommand - це стратегії

Структура стратегії, простіше кажучи, - це більше створення часу поведінки, коли вас не стосується клас реалізації. З іншого боку, фабрика - це створення конкретного екземпляра класу під час виконання, і від вас залежить використання будь-якої поведінки (методу), що піддається реалізованому інтерфейсу.

Ви не можете зрозуміти різницю, просто подивившись на код або категоризацію. Щоб правильно зрозуміти шаблони GoF, шукайте їх наміри:

Стратегія: "Визначте сімейство алгоритмів, інкапсулюйте їх і зробіть їх взаємозамінними. Стратегія дозволяє алгоритму змінюватись незалежно від клієнтів, які ним користуються."

Заводський метод: "Визначте інтерфейс для створення об'єкта, але нехай підкласи вирішують, який клас інстанціювати. Фабричний метод дозволяє відкладати екземпляри класу для підкласів."

І ось детальне пояснення щодо намірів та відмінностей між цими двома моделями: Різниця між заводським методом та моделями стратегії дизайну

Я можу піти на оскар із тим, що його приклад реалізації заводу досить щільно пов'язаний і дуже закритий, недарма ваш вибір - це стратегія. Реалізація на заводі не повинна залежати від будь-якої фіксованої кількості конкретних класів, які використовуються, наприклад:

public Command getCommand( int operatingSystem ) {        
   return commandTable.get(operatingSystem); 
}

...

public class WindowsCommand implements Command {
    ...
    static {
        CommandTable.getInstance().registerCommand(WIN_COMMAND_ID, new WindowsCommand());
    }

}

Я думаю, що найбільш прийнятними критеріями для вибору того чи іншого є, в основному, терміни, які ви використовуєте для назви своїх класів і методів, враховуючи, що всі ми повинні схильні програмувати на інтерфейси, а не на класи, а також орієнтуватися на мету: ми прагнемо визначити який код буде виконуватися під час виконання. З огляду на це, ми можемо досягти мети, використовуючи будь-яку з обох моделей.

Стратегія та Фабрика мають різні цілі. У стратегії у вас визначений підхід, використовуючи цю схему, ви можете змінювати поведінку (алгоритми). На заводі існує багато варіацій. Але оригінальний візерунок із заводу GO4 залишає створення об'єкта дочірньому класу. Тут на заводі ви замінюєте повний екземпляр, а не поведінку, яка вас цікавить. Цим ви заміните повну систему, а не алгоритм.

Фабричний візерунок - це креативний візерунок, який створюється із заданими властивостями (поведінкою). поки час запуску після створення u не може змінити його властивості (поведінку). тож якщо вам потрібні різні властивості (поведінка), ви повинні видалити об'єкт і створити новий об'єкт з необхідними властивостями (поведінка). що не гуд. тоді як у випадку стратегії u може змінити властивості (поведінку) під час виконання.