Читати книгу - "Занурення в патерни проектування, Олександр Швець"

їхніх мето­дів муся­ть пове­рта­ти від­по­від­ні абстра­ктні про­ду­кти. Це дозво­ли­ть кліє­нтсько­го коду, що вико­ри­сто­вує фабри­ку, не прив’язу­ва­ти­ся до конкре­тних кла­сів про­ду­ктів. Кліє­нт зможе пра­цю­ва­ти з будь-якими варіа­ція­ми про­ду­ктів через абстра­ктні інтерфейси. Псе­вдо­код

У цьому при­кла­ді Абстра­ктна фабри­ка ство­рює крос-пла­тфо­рмо­ві еле­ме­нти інте­рфе­йсу і сте­жи­ть за тим, щоб вони від­по­від­а­ли обра­ній опе­ра­ці­йній системі.

При­клад крос-пла­тфо­рмо­во­го гра­фі­чно­го інте­рфе­йсу користувача.

Крос-пла­тфо­рмо­ва про­гра­ма може від­обра­жа­ти одні й ті самі еле­ме­нти інте­рфе­йсу по-різно­му, в зале­жно­сті від обра­ної опе­ра­ці­йної систе­ми. Важли­во, щоб у такій про­гра­мі всі ство­рю­ва­ні еле­ме­нти завжди від­по­від­а­ли пото­чній опе­ра­ці­йній систе­мі. Ви ж не хоті­ли б, аби про­гра­ма, запу­ще­на на Windows, раптом поча­ла пока­зу­ва­ти чек-бокси в стилі macOS?

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

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

Кліє­нтський код не зале­жи­ть від конкре­тних кла­сів фабрик чи еле­ме­нтів інте­рфе­йсу. Він спі­лкує­ться з ними через зага­льні інте­рфе­йси, не зале­жа­чи від конкре­тних кла­сів фабрик чи еле­ме­нтів кори­сту­ва­цько­го інтерфейсу.

Таким чином, щоб дода­ти до про­гра­ми нову варіа­цію еле­ме­нтів інте­рфе­йсу (напри­клад, для під­трим­ки Linux), вам не потрі­бно змі­ню­ва­ти кліє­нтський код. Доста­тньо ство­ри­ти ще одну фабри­ку, що виго­тов­ляє ці елементи.

// Цей патерн передбачає, що ви маєте кілька сімейств продуктів,
// які знаходяться в окремих ієрархіях класів (Button/Checkbox).
// Продукти одного сімейства повинні мати спільний інтерфейс.
interface Button is
  method paint()

// Cімейства продуктів мають однакові варіації (macOS/Windows).
class WinButton implements Button is
  method paint() is
    // Відобразити кнопку в стилі Windows.

class MacButton implements Button is
  method paint() is
    // Відобразити кнопку в стилі macOS.


interface Checkbox is
  method paint()

class WinCheckbox implements Checkbox is
  method paint() is
    // Відобразити чекбокс в стилі Windows.

class MacCheckbox implements Checkbox is
  method paint() is
    // Відобразити чекбокс в стилі macOS.


// Абстрактна фабрика знає про всі абстрактні типи продуктів.
interface GUIFactory is
  method createButton():Button
  method createCheckbox():Checkbox


// Кожна конкретна фабрика знає лише про продукти своєї варіації
// і створює лише їх.
class WinFactory implements GUIFactory is
  method createButton():Button is
    return new WinButton()
  method createCheckbox():Checkbox is
    return new WinCheckbox()

// Незважаючи на те, що фабрики оперують конкретними класами,
// їхні методи повертають абстрактні типи продуктів. Завдяки
// цьому фабрики можна заміняти одну на іншу, не змінюючи
// клієнтського коду.
class MacFactory implements GUIFactory is
  method createButton():Button is
    return new MacButton()
  method createCheckbox():Checkbox is
    return new MacCheckbox()


// Для коду, який використовує фабрику, не важливо, з якою
// конкретно фабрикою він працює. Всі отримувачі продуктів
// працюють з ними через загальні інтерфейси.
class Application is
  private field factory: GUIFactory
  private field button: Button
  constructor Application(factory: GUIFactory) is
    this.factory = factory
  method createUI()
    this.button = factory.createButton()
  method paint()
    button.paint()


// Програма вибирає тип конкретної фабрики й створює її
// динамічно, виходячи з конфігурації або оточення.
class ApplicationConfigurator is
  method main() is
    config = readApplicationConfigFile()

    if (config.OS == "Windows") then
      factory = new WinFactory()
    else if (config.OS == "Mac") then
      factory = new MacFactory()
    else
      throw new Exception("Error! Unknown operating system.")

    Application app = new Application(factory) Засто­су­ва­ння

Коли бізнес-логі­ка про­гра­ми пови­нна пра­цю­ва­ти з різни­ми вида­ми пов’яза­них один з одним про­ду­ктів, неза­ле­жно від конкре­тних кла­сів продуктів.

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

Коли в про­гра­мі вже вико­ри­сто­вує­ться Фабри­чний метод, але черго­ві зміни перед­ба­чаю­ть вве­де­ння нових типів продуктів.

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

Кроки реа­лі­за­ції

Ство­рі­ть табли­цю спів­від­но­ше­нь типів про­ду­ктів до варіа­цій сіме­йств продуктів.

Зве­ді­ть усі варіа­ції про­ду­ктів до зага­льних інтерфейсів.

Визна­чте інте­рфе­йс абстра­ктної фабри­ки. Він пови­нен мати фабри­чні мето­ди для ство­ре­ння кожно­го типу продуктів.

Ство­рі­ть класи конкре­тних фабрик, реа­лі­зу­ва­вши інте­рфе­йс абстра­ктної фабри­ки. Цих кла­сів має бути сті­льки ж, скі­льки й варіа­цій сіме­йств продуктів.

Змі­ні­ть код іні­ціа­лі­за­ції про­гра­ми так, щоб вона ство­рю­ва­ла певну фабри­ку й пере­да­ва­ла її до кліє­нтсько­го коду.

Замі­ні­ть у кліє­нтсько­му коді діля­нки ство­ре­ння про­ду­ктів через кон­стру­ктор на викли­ки від­по­від­них мето­дів фабрики.

Пере­ва­ги та недо­лі­ки