В приложении есть процесс заведения клиентов.
90% полей у клиентов одинаковые и 10% отличаются.

у клиентов также 95% процессов одинаковые и около 5% каждый тип клиента имеет свои.
из этих 95% общих процессов 50% процессов вообще одинаковые и 50% в процессах учитывается своя логика чаще всего основанная на отличающихся 10% полей.

Вопрос.
Как построить бизнес логику для такого.
например операция SaveClient (VIP, Basic, NonResident)

Сейчас сделал на основе паттерна Builder 3 класса VIPClientBuilder, BasicClientBuilder и NonResidentClientBuilder
и в каждом свой набор методов, даже тех которые полностью одинаковые для всех типов клиентов.

Есть смысл общие методы выносить в базовый класс делая методы виртуальными?
Или может предложите варианты получше

Здравствуйте, snaphold, Вы писали:

Если потом с этими полями никакой особой работы не ведется, то я бы в базовом классе мапу завел и пихал бы туда все одноразовые поля

Здравствуйте, snaphold, Вы писали:

S>Или может предложите варианты получше

Анемичные модели плюс проверки на тип клиента в бизнес-логике.

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

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

Затем пишем бизнес-логику:

SaveClient(BaseClient) {
CheckName(baseClient)
if baseClient is CompanyClient then ChecnINN(baseClient as CompanyClient)

switch baseClient {
personClient: PersonClient -> SaveClient(personClient)
companyClient: CompanyClient -> SaveClient(companyClient)
}
}
CheckName(BaseClient) {}
CheckINN(CompanyClient) {}
SaveClient(PersonClient) {}
SaveClient(CompanyClient) {}

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

Здравствуйте, snaphold, Вы писали:

S>В приложении есть процесс заведения клиентов.
S>90% полей у клиентов одинаковые и 10% отличаются.

S>Есть смысл общие методы выносить в базовый класс делая методы виртуальными?
S>Или может предложите варианты получше

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