Як інша популярна мова уникає необхідності використовувати заводський зразок, керуючи подібними складностями, як у Java / Java EE?

Фабрична модель (або принаймні використання FactoryFactory..) - це приклад багатьох жартів, як тут .

Крім того, що мають багатослівні та "креативні" назви, такі як RequestProcessorFactoryFactory.RequestProcessorFactory , чи є щось принципово неправильне з заводською схемою, якщо вам потрібно програмувати в Java / C ++ і чи є примірник для Abstract_factory_pattern ?

Як інша популярна мова (наприклад, Ruby чи Scala ) уникає необхідності користуватися нею при керуванні подібною складністю?

Причину, про яку я питаю, я бачу здебільшого критику заводів, згаданих у контексті екосистеми Java / Java EE , але вони ніколи не пояснюють, як інші мови / рамки їх вирішують.

Ваше запитання позначено "Java", не дивно, що ви запитуєте, чому знущається з "Фабричного шаблону": сама Java надходить з добре упакованими зловживаннями цього шаблону.

Наприклад, спробуйте завантажити XML-документ із файлу та запустіть запит XPath проти нього. Вам потрібно щось на зразок 10 рядків коду просто для налаштування Фабрик та будівельників:

DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = builderFactory.newDocumentBuilder(); 

Document xmlDocument = builder.parse(new FileInputStream("c:\\employees.xml"));
XPath xPath =  XPathFactory.newInstance().newXPath();

xPath.compile(expression).evaluate(xmlDocument);

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

Оскільки ви запитуєте, яка альтернатива, тут ви завантажуєте XML-файл у C #:

XDocument xml = XDocument.Load("c:\\employees.xml");
var nodes = xml.XPathSelectElements(expression);

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

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

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

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

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

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

У системі була нормалізована база даних до 5-ї нормальної форми (я вам цього не знаю).

Система, яка по суті була трохи більше, ніж адресна книга, яка могла використовуватися для реєстрації та відстеження вхідних та вихідних документів, мала кодову базу даних 100 МБ у C ++ та понад 50 таблиць баз даних. Друк 500 форм листів займе 72 години за допомогою принтера, підключеного безпосередньо до комп'ютера, на якому працює програмне забезпечення.

Ось чому люди знущаються над моделями, а конкретно з людьми, що однозначно зосереджуються на одному конкретному шаблоні.

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

WidgetFactory redWidgetFactory = new ColoredWidgetFactory(COLOR_RED);
Widget widget = redWidgetFactory.create();

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

WidgetBuilder widgetBuilder = new WidgetBuilder();
widgetBuilder.setColor(COLOR_RED);
Widget widget = widgetBuilder.create();

Але коли надмірна інженерія - це ваша проблема, заміна Заводу на будівельника, швидше за все, не буде значною мірою поліпшенням.

Найпростіша заміна для будь-якого шаблону - це, звичайно, створення об’єктів-об'єктів за допомогою простого конструктора з newоператором:

Widget widget = new ColoredWidget(COLOR_RED);

Однак у конструкторів є важливий недолік у більшості об'єктно-орієнтованих мов: вони повинні повернути об'єкт саме цього класу і не можуть повернути підтип.

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

 Widget widget = Widget.createColoredWidget(COLOR_RED); // returns an object of class RedColoredWidget

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

Фабрики того чи іншого виду знаходяться майже в будь-якій об'єктно-орієнтованій мові за відповідних обставин. Іноді просто потрібен спосіб вибрати тип об’єкта для створення на основі простого параметра, такого як рядок.

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

Що мене вразило, коли я дізнався Scala, і я не знаю Ruby, але вважаю, що це так само, це те, що мова є достатньо виразною, що програмісти не завжди намагаються підштовхнути "сантехнічну" роботу до зовнішніх файлів конфігурації . Замість того, щоб спокуситись створити фабричні фабрики, щоб з'єднати свої класи разом у різних конфігураціях, у Scala ви використовуєте об'єкти із змішаними ознаками. Це також відносно просто створити прості DSL-мови на мові для завдань, які часто перероблені на Java.

Крім того, як вказували інші коментарі та відповіді, закриття та функції першого класу усувають потребу у багатьох моделях. З цієї причини, я вірю, що багато анти-шаблонів почнуть зникати, коли C ++ 11 і Java 8 набули широкого поширення.

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

Зокрема, проблема, яку Java має з фабриками, полягає в тому, що в Java а) конструктори не є функціями, а б) функції не є першокласними громадянами.

Уявіть, що ви можете написати щось подібне (нехай це Functionбуде відомий інтерфейс JRE )

// Framework code
public Node buildTree(Function<BranchNode, Node, Node> branchNodeFactory) {
    Node current = nextNode();
    while (hasNextNode()) {
        current = branchNodeFactory.call(current, nextNode());
    }
    return current
}

// MyDataNode.java
public class MyBranchNode implements BranchNode {

    public MyBranchNode(Node left, Node right) { ... }
}

// Client code
Node root = buildTree(MyBranchNode::new);

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

Отже, альтернативою є не стільки "використання іншого шаблону", а більше "використання мови з кращою об'єктною моделлю" або "не надмірно спроможні проблеми".