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

class="cm-def1">HTMLButton implements Button is
  method render(a, b) is
    // Повернути HTML-код кнопки.
  method onClick(f) is
    // Навісити на кнопку обробник події браузера.


// Базовий клас фабрики. Зауважте, що "фабрика" — це всього лише
// додаткова роль для цього класу. Скоріше за все, він вже має
// якусь бізнес-логіку, яка потребує створення продуктів.
class Dialog is
  method render() is
    // Щоб використати фабричний метод, ви маєте
    // пересвідчитися, що ця бізнес-логіка не залежить від
    // конкретних класів продуктів. Button — це загальний
    // інтейрфейс кнопок, тому все гаразд.
    Button okButton = createButton()     okButton.onClick(closeDialog)
    okButton.render()

  // Ми виносимо весь код створення продуктів до особливого
  // методу, який називають "фабричним".
  abstract method createButton():Button


// Конкретні фабрики перевизначають фабричний метод і повертають
// з нього власні продукти.
class WindowsDialog extends Dialog is
  method createButton():Button is
    return new WindowsButton()

class WebDialog extends Dialog is
  method createButton():Button is
    return new HTMLButton()


class Application is
  field dialog: Dialog

  // Програма створює певну фабрику в залежності від
  // конфігурації або оточення.
  method initialize() is
    config = readApplicationConfigFile()

    if (config.OS == "Windows") then
      dialog = new WindowsDialog()
    else if (config.OS == "Web") then
      dialog = new WebDialog()
    else
      throw new Exception("Error! Unknown operating system.")

  // Якщо весь інший клієнтський код працює з фабриками та
  // продуктами тільки через загальний інтерфейс, то для нього
  // байдуже, якого типу фабрику було створено на початку.
  method main() is
    this.initialize()
    dialog.render() Засто­су­ва­ння

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

Фабри­чний метод від­окре­млює код виро­бни­цтва про­ду­ктів від решти коду, який вико­ри­сто­вує ці продукти.

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

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

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

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

Напри­клад, ви вико­ри­сто­вує­те гото­вий UI-фре­ймво­рк для свого дода­тку. Але — от хале­па — вам нео­бхі­дно мати кру­глі кно­пки, а не ста­нда­ртні пря­мо­ку­тні. Ви ство­рює­те клас RoundButton. Але як ска­за­ти голо­вно­му класу фре­ймво­рку UIFramework, щоб він почав тепер ство­рю­ва­ти кру­глі кно­пки замі­сть ста­нда­ртних пря­мо­ку­тних?

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

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

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

Уяві­ть, скі­льки дій вам потрі­бно зро­би­ти, аби повто­рно вико­ри­сто­ву­ва­ти вже існую­чі об’єкти:

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

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

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

Отже, має бути інший метод, який би від­да­вав як існую­чі, так і нові об’єкти. Ним і стане фабри­чний метод.

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

При­ве­ді­ть усі ство­рю­ва­ні про­ду­кти до зага­льно­го інтерфейсу.

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

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

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

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

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

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

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

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