Архитектура: изменение модели по-разному

Ответ 1

Хотя вы не указываете это явно, рефакторинг тысяч строк кода является сложной задачей, и я предполагаю, что какой-то инкрементный процесс предпочтительнее всего или ничего.

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

Поэтому я бы предложил использовать "Фасад" , главным образом по этой причине:

обернуть плохо разработанную коллекцию API с помощью одного хорошо разработанного API (в соответствии с задачами)

Потому что это в основном то, что у вас есть: коллекция API в одном классе, которую нужно разделить на разные группы. Каждая группа получала свой собственный Фасад со своими собственными вызовами. Итак, текущий MyModelItem, со всеми его тщательно обработанными различными вызовами метода за эти годы:

...
void setText(String s);
void setTextGUI(String s); // different name
void setText(int handler, String s); // overloading
void setTextAsUnmentionedSideEffect(int state);
...

становится:

class FacadeInternal {
    setText(String s);
}
class FacadeGUI {
    setTextGUI(String s);
}
class FacadeImport {
    setText(int handler, String s);
}
class FacadeSideEffects {
    setTextAsUnmentionedSideEffect(int state);
}

Если мы удалим текущие элементы в MyModelItem в MyModelItemData, мы получим:

class MyModelItem {
    MyModelItemData data;

    FacadeGUI& getFacade(GUI client) { return FacadeGUI::getInstance(data); }
    FacadeImport& getFacade(Importer client) { return FacadeImport::getInstance(data); }
}

GUI::setText(MyModelItem& item, String s) {
    //item.setTextGUI(s);
    item.getFacade(this).setTextGUI(s);
}

Конечно, здесь существуют варианты реализации. Это также можно было бы:

GUI::setText(MyModelItem& item, String s) {
    myFacade.setTextGUI(item, s);
}

Это больше зависит от ограничений на память, создания объектов, concurrency и т.д. Дело в том, что до сих пор все прямо (я не буду говорить "поиск и замена" ), а компилятор помогает каждый шаг на пути к сбою ошибок.

Хорошая вещь в Facade заключается в том, что он может сформировать интерфейс для нескольких библиотек/классов. После разделения вещей бизнес-правила находятся на нескольких фасадах, но вы можете реорганизовать их дальше:

class FacadeGUI {
    MyModelItemData data;
    GUIValidator validator;
    GUIDependentData guiData;

    setTextGUI(String s) {
        if (validator.validate(data, s)) {
            guiData.update(withSomething)
            data.setText(s);
        }
    }
}

и код GUI не нужно менять один бит.

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

(Я знаю, что сильно подчеркиваю компилятор, но, по моему опыту, когда все имеет одно и то же имя и работает через один или несколько уровней косвенности, становится больно узнать, где и когда что-то действительно происходит неправильно.)

Во всяком случае, так я бы это сделал, так как он позволяет довольно быстро распределять большие куски кода, контролируя его, не задумываясь слишком много. Это обеспечивает хороший шаг для дальнейшей настройки. Я предполагаю, что в какой-то момент класс MyModelItem должен быть переименован в MyModelItemMediator.

Удачи вам в вашем проекте.

Ответ 2

Обычный strategy шаблон кажется лучшей стратегией для меня.

Из вашего утверждения я понимаю:

• Модель изменена.
• мутация может произойти с помощью другого источника. (т.е. разные классы)
• модель должна проверять каждое усилие мутации.
• В зависимости от источника усилия проверка процесса отличается.
• модель не обращает внимания на источник и процесс. его главной задачей является состояние объекта, который он моделирует.

Предложение:

• пусть Источник - это классы, которые каким-то образом мутируют модель. это могут быть десериализаторы, пользовательский интерфейс, импортеры и т.д.
• пусть валидатор - это интерфейс/суперкласс, который содержит основную логику проверки. он может иметь такие методы, как: validateText(String), validateState(ItemState)...
• Каждый Источник имеет валидатор. Этот валидатор может быть экземпляром базового валидатора или может наследовать и переопределять некоторые из его методов.
• Каждый валидатор имеет ссылку на модель.
• Источник сначала устанавливает свой собственный валидатор, затем выполняет попытку мутации.

Теперь,

Source1                   Model                  Validator
   |     setText("aaa")     |                        |
   |----------------------->|    validateText("aaa") |
   |                        |----------------------->|
   |                        |                        |
   |                        |       setState(2)      |
   |          true          |<-----------------------|
   |<-----------------------|                        |

поведение разных валидаторов может быть различным.

Ответ 3

Если я правильно понимаю вашу проблему, тогда я бы не решил, какой шаблон дизайна выбрать. Я думаю, что я видел такой код несколько раз раньше, и основная проблема в моей точке зрения всегда заключалась в том, что изменения основывались на изменениях, связанных с изменениями. Класс потерял свою первоначальную цель и теперь выполняет несколько целей, которые все четко не определены и не установлены. Результатом является большой класс (или большая база данных, код спагетти и т.д.), Который, кажется, незаменим, но является кошмаром для обслуживания.

Большой класс является симптомом процесса, который вышел из-под контроля. Здесь вы можете увидеть, как это происходит, но я предполагаю, что когда этот класс будет восстановлен, многие другие классы будут первыми, кто перепроектирует. Если я прав, то есть также много искажений данных, потому что во многих случаях определение данных неясно.

Мой совет будет возвращаться к вашему клиенту, говорить о бизнес-процессах, реорганизовать управление проектами приложения и попытаться выяснить, хорошо ли приложение все еще служит бизнес-процессу. Это может быть не так - я несколько раз был в этом виде ситуации в разных организациях. Если понимать бизнес-процесс и преобразовать модель данных в соответствие с новой моделью данных, то вы можете заменить приложение новым дизайном, который намного проще создать. Большой класс, который сейчас существует, больше не нуждается в реорганизации, потому что его причина существования исчезла. Это стоит денег, но обслуживание теперь стоит и денег. Хорошим показателем для редизайна является то, что новые функции больше не реализованы, потому что они стали слишком дорогими или подвержены ошибкам.

Ответ 4

Я постараюсь дать вам другую точку зрения на ситуацию, которая у вас есть. Обратите внимание, что объяснения написаны моими словами для простоты. Однако упомянутые термины относятся к шаблонам архитектуры корпоративного приложения.

Вы разрабатываете бизнес-логику приложения. Таким образом, MyModelItem должен быть своего рода бизнес-объектом. Я бы сказал, что у вас есть Active Record.

Активная запись: бизнес-объект, который может сам CRUD, и может управлять бизнес-логика, связанная с самим собой.

Бизнес-логика, содержащаяся в Active Record, увеличилась и стала трудно управлять. Эта очень типичная ситуация с Active Records. Здесь вы должны перейти от шаблона активной записи к шаблону Data Mapper.

Data Mapper: механизм (обычно класс), управляющий отображением (обычно между объектом и данными, которые он переводит с/на). Это начинается, когда проблемы с отображением Active Record что они должны быть помещены в отдельный класс. Сопоставление становится логикой само по себе.

Итак, мы пришли к очевидному решению: создадим Data Mapper для объекта MyModelItem. Упростите объект так, чтобы он не обрабатывал отображение самого себя. Перенесите управление сопоставлением в Data Mapper.

Если MyModelItem принимает участие в наследовании, подумайте о создании абстрактного Data Mapper и конкретных Data Mappers для каждого конкретного класса, который вы хотите сопоставить по-другому.

Несколько замечаний о том, как я его реализую:

• Сделать сущность осведомленной о картере.
• Mapper - это поисковик объекта, поэтому приложение всегда начинается с mapper.
• Сущность должна раскрывать функциональность, которая естественна для нее.
• И субъект использует (абстрактный или конкретный) сборщик для выполнения конкретных вещей.

В общем, вы должны моделировать свое приложение без учета данных. Затем, проектор mapper для управления преобразованиями из объектов в данные и вице verca.

Теперь о проверке

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

Если проверка отличается и зависит от чего-то, отвлеките что-нибудь и вызовите проверку через абстракцию. Один из способов (если это зависит от наследования) заключается в том, чтобы поставить валидацию в mapper или иметь ее в том же семействе объектов, что и mapper, созданный общей темой Factory.