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

Question

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

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

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

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

Answer 1

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

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

class MercedesBenzC300Business : MercedesBenzC300 
{ 
    int EnableCruiseControl(); 
} 

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

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 

Это прекрасно работает, если у вас есть несколько таких возможностей, и они делают очень маленькие вещи (представима в несколько строк кода). Если некоторые из этих функций тяжелы, они могут быть инкапсулированы в отдельный класс с помощью известного интерфейса. Это известно как Стратегия шаблон. Затем эта стратегия вводится 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 и использовать любой из них для разных случаев. Например. один для тестов и один для производства.