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

Також відомий як: Віртуальний конструктор, Factory Method

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

Про­бле­ма

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

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

Дода­ти новий клас не так про­сто, якщо весь код вже зале­жи­ть від конкре­тних класів.

Чудо­ві нови­ни, чи не так?! Але як щодо коду? Вели­ка части­на існую­чо­го коду жорстко прив’язана до кла­сів Вантажівок. Щоб дода­ти до про­гра­ми класи морських Суден, зна­до­би­ться пере­ло­па­чу­ва­ти весь код. Якщо ж ви вирі­ши­те дода­ти до про­гра­ми ще один вид тра­нс­по­рту, тоді всю цю робо­ту дове­де­ться повторити.

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

Ріше­ння

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

Під­кла­си можу­ть змі­ню­ва­ти клас ство­рю­ва­них об’єктів.

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

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

Всі об’єкти-про­ду­кти пови­нні мати спі­льний інтерфейс.

Напри­клад, класи Вантажівка і Судно реа­лі­зую­ть інте­рфе­йс Транспорт з мето­дом доставити. Кожен з цих кла­сів реа­лі­зує метод по-своє­му: ванта­жі­вки пере­во­зя­ть ванта­жі сушею, а судна — морем. Фабри­чний метод класу ДорожноїЛогістики пове­рне об’єкт-ванта­жі­вку, а класу МорськоїЛогістики — об’єкт-судно.

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

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

Стру­кту­ра

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

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

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

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

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

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

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

Псе­вдо­код

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

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

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

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

Такий під­хід можна засто­су­ва­ти і для ство­ре­ння інших еле­ме­нтів інте­рфе­йсу. Хоча кожен новий тип еле­ме­нтів набли­жа­ти­ме вас до Абстра­ктної фабри­ки.

// Патерн Фабричний метод має сенс лише тоді, коли в програмі є
// ієрархія класів продуктів.
interface Button is
  method render()
  method onClick(f)

class WindowsButton implements Button is
  method render(a, b) is
    // Відобразити кнопку в стилі Windows.
  method onClick(f) is
    // Навісити на кнопку обробник подій Windows.

class