ООП: Каким должен быть правильный дизайн класса в этой ситуации?

Question

У меня есть объект guiObject, который поступает из GUI.На основании его полей данных мне нужно создать экземпляр domainObject соответствующего класса.Это может быть DomainClassA или DomainClassB.

DomainClassA имеет один параметр целочисленного конструктора intParamA (из guiObject.fieldA).

DomainClassB имеет один параметр целочисленного конструктора intParamB (из guiObject.fieldB).

Чтобы решить эту проблему, я сделал AbstractFactory, который берет обязательные поля из guiObject, создает экземпляр либо DomainClassAFactory или DomainClassBFactory с соответствующими полями из GuiClass, и выполняет повторную настройку.В свою очередь, любой из этих заводов create() должным образом создан domainObject.

Но теперь, в зависимости от guiObject.fieldC мне нужно изменить intParamA и intParamB (т.е. уменьшить на 1) перед созданием экземпляра domainObject.Чтобы достичь этого, я должен был создать отдельные фабрики для каждого «типа изменения параметров» для каждого DomainClass, а затем создать отдельные абстрактные фабрики, которые производят правильные фабрики.Это звучит ужасно и выглядит ужасно.

Каким должен быть правильный дизайн?

Answer 1

Если вам не нужно всех этих слоев, создайте фабрику, которая опрашивает guiObject и возвращает правильный тип.

Излишний анализ приводит к слишком большому количеству вещей, которые большинство приложений простоне нужноДобавляйте дополнительные слои абстракции, только если они строго необходимы.Обычно это не так.

Answer 2

Я бы лично применил всю эту логику к оригинальной фабрике, а не пытался распространять ее так сильно:

public DomainObj getDomainObj(GuiObject guiObject) {
    int param = guiObject.someField ? guiObject.intParamA : guiObject.intParamB;
    param = guiObject.fieldC ? param : param - 1;
    return guiObject.someField ? new DomainClassA(param) : new DomainClassB(param);
}