Хороший шаблон дизайна для почти похожих объектов

Question

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

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

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

например, у меня есть метод createAccount(Account account) в моем классе DAO, но реализация будет немного отличаться для веб-сайта A и веб-сайта B.

Answer 1

Если реализация объектов также будет почти такой же, я бы предложил использовать абстрактный базовый класс. Расширьте класс наследованием и убедитесь, что ваши функции, которые не знают о расширенном поле, нуждаются в базовом классе, а не в производном классе.

class MercedesBenzC300 : Car
{
     int brake();
     void TurnOnRadio();
}

class MercedesBenzC300Business : MercedesBenzC300
{
    int EnableCruiseControl();
}

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

Answer 2

Слишком мало деталей, чтобы сказать что-то конкретное, но я попробую. Это зависит от сложности ситуации, но вы можете быть довольны простой параметризацией, которая включает / выключает функции:

class AccountRepository:
    def constructor(have_feature_a, have_feature_b, etc):
        # ...

    def create_account(account):
        if have_feature_a:
            # do something special
        # do common operations
        if have_feature_b:
            # do another special thing

Это прекрасно работает, если у вас мало таких функций и они делают очень маленькие вещи (представимые в нескольких строках кода) Если некоторые из этих функций тяжелые, они могут быть заключены в отдельный класс с известным интерфейсом. Это называется шаблоном Strategy . Затем эта стратегия вводится AccountRepository как зависимость. Это известно как DI или Dependency Injection :

class AccountRepository:
    def constructor(have_feature_a, feature_b_worker, etc):
        # ...

    def create_account(account):
        if have_feature_a:
            # do something special
        # do common operations
        if feature_b_worker != null:
            # line bellow runs heavy code encapsulated in strategy
            feature_b_worker.do_work(account)

Теперь вы можете даже иметь несколько реализаций FeatureB и использовать любую из них для разных случаев. Например. один для испытаний и один для производства.