Какой дизайн лучше?

Question

У меня есть объект лидера команды, и у меня есть много членов команды, принадлежащих лидеру команды. И руководитель группы, и члены команды имеют функцию «writeDB».

Итак, дизайн 1:

Have a common writeDB function in DBUtility:
teamLeader.writeDB(); //calling DBUtility like this DBUtility.insert(self);
teamMember.writeDB(); //calling DBUtility like this DBUtility.insert(self);

дизайн 2:

Both implementing a writeDB Interface:
teamLeader.writeDB(); //implement the write DB itself;
teamMember.writeDB(); //implement the write DB itself;

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

дизайн 2 может разделить код на две части. Если один разработчик пишет о логике teamLeader, ему не нужно обновлять DBUtility, а также, если код перемещается куда-то еще, ему не нужно копировать бесполезную функцию, например, функция teamMember writeDB DBUtility не нужна ,

Что вы думаете для лучшего поддержания? или дизайн 3 от вас. Спасибо.

Answer 1

Почему TeamMember и TeamLeader вообще должны знать о базе данных? Я думаю, что это было бы лучше:

DBUtility.write( teamMember );
DBUtility.write( teamLeader );

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

DBUtility dbUtility = new DBUtility( dbConnection );
dbUtility.write( teamMember );
dbUtility.write( teamLeader );

Затем, возможно, вам потребуется записать на диск в формате XML. Вы должны иметь возможность добавить эту функцию, не меняя свои TeamLeader и TeamMember.

XMLUtility xmlUtility = new XMLUtility( stream );
xmlUtility.write( teamMember );
xmlUtility.write( teamLeader );

Answer 2

Оставляя в стороне мое беспокойство, что любой класс уровня модели будет иметь явный открытый метод writeDB, я бы выбрал вариант 1

.

Стойкость следует считать ортогональной основным обязанностям этих классов .

Преимущество состоит из нескольких частей

• Чистое разделение обязанностей приведет к более объектно-ориентированный дизайн. Более объектно-ориентированный означает более понятный и простой в управлении со временем.

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

• Когда вы неизбежно освобождаете эту базу данных X лучше, чем база данных Y (или действительно, SQL - плохая идея), логика персистентности не распространяется по всей базе кода

Это надоедливый метод writeDB ()

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

Answer 3

Второй вариант, безусловно, более OO. Каждый тип реализует интерфейс writeDB. Если при написании teamLeader имеет смысл также написать каждый teamMember, тогда имплементация writeDB для teamLeader может вызвать writeDB для каждого teamMember.

Это было бы наиболее оптимальным решением.

Однако, это не учитывает ограничения и эффективность постоянного уровня.

Answer 4

Это зависит.Из принципа разделения интересов это не должно относиться к самому классу, но наличие класса, который знает обо всех остальных, нарушает принцип Open-Close.

Существует третий вариант для такого родаоперация (например, запись в БД), то есть использование некоторых метаданных в классе, а затем некоторый код, который записывает объект в базу данных, используя информацию метаданных.

Answer 5

Я должен пойти с дизайном 2, который заставит все мои классы иметь метод writeDB, и я буду использовать design1 для обеспечения этой функциональности.

Таким образом, у меня будет интерфейс для моих объектов Leader / Member и я будуиметь действия, сгруппированные по классу, который знает, как выполнять действия.

Answer 6

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