Чому я повинен використовувати заводський клас замість прямого об'єкта?

Я бачив історію декількох проектів бібліотек класів С # та Java на GitHub та CodePlex, і бачу тенденцію переходу на фабричні класи на відміну від прямого об'єкта.

Чому я повинен широко використовувати фабричні заняття? У мене досить гарна бібліотека, де об’єкти створюються старомодним способом - шляхом виклику громадських конструкторів класів. В останніх комісіях автори швидко змінили всіх публічних конструкторів тисяч класів на внутрішні, а також створили один величезний заводський клас з тисячами CreateXXXстатичних методів, які просто повертають нові об'єкти, викликаючи внутрішні конструктори класів. API зовнішнього проекту зламаний, молодець.

Чому така зміна була б корисною? Який сенс рефакторингу таким чином? Які переваги замінюють дзвінки конструкторам загальнодоступного класу статичними викликами фабричних методів?

Коли я повинен використовувати громадські будівельники і коли слід використовувати заводи?

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

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

• Це дозволяє легко ввести контейнер Інверсії управління (IoC)
• Це робить ваш код більш випробуваним, оскільки ви можете знущатися над інтерфейсами
• Це дає вам набагато більше гнучкості, коли настає час змінити додаток (тобто ви можете створювати нові реалізації без зміни залежного коду)

Розглянемо цю ситуацію.

Збірка A (-> засоби залежить від):

Class A -> Class B
Class A -> Class C
Class B -> Class D

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

Асамблея A:

Class A -> Interface IB
Class A -> Interface IC
Class B -> Interface IB
Class C -> Interface IC
Class B -> Interface ID
Class D -> Interface ID

Тепер я можу перенести клас В на збірку В, не маючи болю. Це все ще залежить від інтерфейсів у збірці A.

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

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

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

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

Багато заводів створюються, тому що "Можливо, одного разу мені потрібно буде створити ці класи по-іншому" на увазі. Що є явним порушенням YAGNI .

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

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

Фабрика модельних моделей випливає з майже догматичної віри серед кодерів в мовах "стилю С" (C / C ++, C #, Java), що використання "нового" ключового слова є поганим, і його слід уникати будь-якою ціною (або за будь-яку ціну найменш централізовані). Це, у свою чергу, випливає з надто суворої інтерпретації Принципу єдиної відповідальності ("S" SOLID), а також принципу інверсії залежності ("D"). Простіше кажучи, SRP говорить, що в ідеалі кодовий об'єкт повинен мати одну "причину для зміни", і лише одну; що "причина зміни" є основною метою цього об'єкта, його "відповідальністю" в кодовій базі, і будь-що інше, що вимагає зміни коду, не повинно вимагати відкриття файлу класу. DIP ще простіший; об'єкт коду ніколи не повинен залежати від іншого конкретного об'єкта,

Справа в конкретному випадку, використовуючи "новий" і загальнодоступний конструктор, ви з'єднуєте код виклику з конкретним методом побудови конкретного класу конкретних. Тепер ваш код повинен знати, що клас MyFooObject існує і має конструктор, який приймає рядок і int. Якщо цьому конструктору коли-небудь потрібна додаткова інформація, усі звички конструктора повинні бути оновлені, щоб передати цю інформацію, включаючи ту, яку ви зараз пишете, і тому вони повинні мати щось дійсне для передачі, і тому вони повинні або мати його або бути зміненим, щоб отримати його (додавши більше обов'язків до споживаючих об'єктів). Крім того, якщо MyFooObject коли-небудь замінюється в кодовій базі на BetterFooObject, всі звички старого класу повинні змінитися, щоб сконструювати новий об'єкт замість старого.

Отже, натомість усі споживачі MyFooObject повинні бути безпосередньо залежні від "IFooObject", який визначає поведінку впроваджуючих класів, включаючи MyFooObject. Тепер споживачі IFooObjects не можуть просто побудувати IFooObject (не маючи знання про те, що конкретний конкретний клас є IFooObject, який їм не потрібен), тому натомість їм слід надати примірник класу чи методу, що реалізує IFooObject. ззовні, іншим об'єктом, який несе відповідальність за знання того, як створити правильний IFooObject для тієї обставини, яка на нашому мові зазвичай називається Фабрикою.

Тепер ось теорія відповідає дійсності; об'єкт ніколи не може бути закритий для всіх типів змін. Справа в тому, IFooObject тепер є додатковим кодовим об'єктом у кодовій базі, який повинен змінюватися щоразу, коли інтерфейс, необхідний споживачам або реалізація IFooObjects, змінюється. Це вводить новий рівень складності, пов'язаний із зміною способу взаємодії об'єктів один з одним у цій абстракції. Крім того, споживачам доведеться все-таки змінитись і ще глибше, якщо сам інтерфейс буде замінений на новий.

Хороший кодер знає, як збалансувати YAGNI ("Вам це не знадобиться") з SOLID, проаналізувавши дизайн та знайди місця, які, ймовірно, повинні змінитися певним чином, і переробляти їх на більш толерантність до такий тип змін, тому що в такому випадку "вам це знадобиться".

Конструктори добре, коли містять короткий простий код.

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

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

• У деяких мовах та деяких випадках кидання винятків у конструкторах - це дійсно погана ідея , оскільки може вводити помилки.

• Коли ви викликаєте конструктор, вам, абоненту, потрібно знати точний тип екземпляра, який ви бажаєте створити. Це не завжди так (як-от Feeder, мені просто потрібно сконструювати Animal, щоб годувати його; мені все одно, чи це Dogа Cat).

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

Один простий приклад: ви хочете спілкуватися з пристроєм, але не знаєте, чи буде це через Ethernet, COM або USB. Ви визначаєте один інтерфейс і 3 реалізації. Після цього ви можете вибрати метод, який ви хочете, і фабрика дасть вам відповідну реалізацію.

Використовуйте його часто ...

Це симптом обмеження в модульних системах Java / C #.

В принципі, немає жодної причини, щоб ви не могли мати можливість замінювати одну реалізацію класу на іншу тим самим підписом конструктора та методу. Там є мови , які дозволяють це. Однак Java та C # наполягають на тому, що кожен клас має унікальний ідентифікатор (повністю кваліфіковане ім'я), і клієнтський код закінчується жорсткою кодовою залежністю від нього.

Ви можете роду обійти це возилися з файлової системою і опцією компілятора , так що com.example.Fooкарти до іншого файлу, але це дивно і неінтуітівнимі. Навіть якщо ви це зробите, ваш код все одно пов'язаний лише з однією реалізацією класу. Тобто, якщо ви пишете клас, Fooякий залежить від класу MySet, ви можете вибрати реалізацію MySetв час компіляції, але ви все ще не можете інстанціювати Foo, використовуючи дві різні реалізації MySet.

Це невдале дизайнерське рішення змушує людей використовувати interfaces без необхідності для підтвердження свого коду в майбутньому проти можливості того, що їм пізніше буде потрібно щось реалізувати чи полегшити тестування одиниць. Це не завжди можливо; якщо у вас є якісь методи, які розглядають приватні поля двох екземплярів класу, не вдасться реалізувати їх в інтерфейсі. Ось чому, наприклад, ви не бачите unionв Setінтерфейсі Java . Тим не менше, за винятком числових типів і колекцій, бінарні методи не є звичайними, тому зазвичай ви можете піти з нею.

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

Ви вирішуєте, чи варто роздувати вашу кодову базу інтерфейсами та фабриками. З одного боку, якщо відповідний клас є внутрішнім у вашій кодовій базі, рефакторинг коду таким чином, щоб він використовував інший клас чи інтерфейс, в майбутньому є тривіальним; ви можете викликати YAGNI та рефактор пізніше, якщо виникла ситуація. Але якщо клас є частиною публічного API бібліотеки, яку ви опублікували, у вас немає можливості виправити клієнтський код. Якщо ви не скористаєтеся interfaceі не потребуєте декількох реалізацій, то ви застряжете між скелею і важким місцем.

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

А оскільки вони створили "величезний клас тканини з тисячами статичних методів CreateXXX", це звучить як анти-візерунок (можливо, клас Бога?).

Я думаю, що методи Simple Factory і статичні творці (які не потребують зовнішнього класу) можуть бути корисними в деяких випадках. Наприклад, коли побудова об'єкта вимагає різних кроків, таких як інстанція інших об'єктів (наприклад, надання переваги композиції).

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

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

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

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

Це здається застарілим у епоху Scala та функціонального програмування. Міцна основа функцій замінює газильйонні класи.

Також слід зазначити, що подвійний Java {{більше не працює при використанні фабрики, тобто

someFunction(new someObject() {{
    setSomeParam(...);
    etc..
}})

Що дозволяє вам створити анонімний клас та налаштувати його.

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