В приложении есть процесс заведения клиентов.
90% полей у клиентов одинаковые и 10% отличаются.
у клиентов также 95% процессов одинаковые и около 5% каждый тип клиента имеет свои.
из этих 95% общих процессов 50% процессов вообще одинаковые и 50% в процессах учитывается своя логика чаще всего основанная на отличающихся 10% полей.
Вопрос.
Как построить бизнес логику для такого.
например операция SaveClient (VIP, Basic, NonResident)
Сейчас сделал на основе паттерна Builder 3 класса VIPClientBuilder, BasicClientBuilder и NonResidentClientBuilder
и в каждом свой набор методов, даже тех которые полностью одинаковые для всех типов клиентов.
Есть смысл общие методы выносить в базовый класс делая методы виртуальными?
Или может предложите варианты получше
Здравствуйте, snaphold, Вы писали:
S>Или может предложите варианты получше
Анемичные модели плюс проверки на тип клиента в бизнес-логике.
Я исхожу из того, что типов клиентов ограниченное количество и добавление нового типа клиента без изменения кода бессмысленно, есть какой-то набор полей, гарантированно общий для всех типов клиентов, есть операции, общие для всех типов клиентов, но с дополнительной логикой, в зависимости от типа клиента.
Делаем базовый класс клиента с виртуальными методами-геттерами и по потомку на каждый тип клиента, реализующий эти методы плюс добавляющий специфичные поля для типа клиента. Эта модель не содержит никакой логики.
Затем пишем бизнес-логику:
SaveClient(BaseClient) {
CheckName(baseClient)
if baseClient is CompanyClient then ChecnINN(baseClient as CompanyClient)
Никакого ООП, никакого наследования логики, просто набор независимых функций. Если ваш язык поддерживает sealed иерархии и паттерн матчинг, то можно обойтись без некрасивых преобразований типов и проще добавлять новых клиентов.
Здравствуйте, snaphold, Вы писали:
S>В приложении есть процесс заведения клиентов. S>90% полей у клиентов одинаковые и 10% отличаются.
S>Есть смысл общие методы выносить в базовый класс делая методы виртуальными? S>Или может предложите варианты получше
Есть смысл сделать один класс клиента, у которого заполнять часть полей в зависимости от "типа". SaveClient будет использовать один класс клиента.
В первую очередь потому что указанные вами "типы" клиентов не выглядят как конечный набор взаимоисключающих типов. Вполне может быть VipNonResidentClient.