Разработка пользовательских классов

Question

Разработка пользовательских классов

1

Я работаю над нижеследующими вариантами использования.

Создать пользователя
Удалить пользователя
Обновить пользователя

Теперь я могу спроектировать его двумя способами

Дизайн # 1 - Создание класса UserOperations → Имеет в общей сложности 3 метода, по одному методу для создания, удаления и обновления User.
Дизайн # 2 - создание 3 классов → класс CreateUser, класс DeleteUser и класс UpdateUser.

Согласно SRP (принцип единой ответственности), как и в принципах SOLID, я чувствую, что у нас есть 3 обязанности, которые создают пользователя, удаляя пользователя и обновляя пользователя, и поэтому нам нужно 3 класса, как упомянуто выше в пункте 2.

Пожалуйста, предложите, какой должен быть хороший дизайн - Design # 1 или Design # 2.

Manish 25 авг. 2014, в 09:50

Источник

0

Шаблон фабрики или менеджера позволил бы вам использовать дизайн # 1, где управление жизненным циклом является исключительной ответственностью фабрики или менеджера. Конечно, это может быть дизайн # 2 ...;)
MadProgrammer 25 авг. 2014, в 07:40
0

создавать , удалять и обновлять поведения (методы). Более целесообразно иметь один класс и один или несколько вспомогательных классов, поддерживающих его, вместо трех классов.
TheLostMind 25 авг. 2014, в 07:43
0

@MadProgrammer, так какой дизайн вы бы предложили?
Manish 25 авг. 2014, в 07:44
0

@TheLostMind, но создание обновления и удаление - это три разные вещи, и они не связаны друг с другом, поэтому, когда я делаю создание, мне не нужно удалять и т. Д. Так что я чувствую, что они должны идти в разные классы.
Manish 25 авг. 2014, в 07:44
0

Лично у меня был бы центральный менеджер, ответственный за весь жизненный цикл объекта, но это я ...
MadProgrammer 25 авг. 2014, в 07:44
0

@Manish - Ваш дизайн косвенно связан. Вы должны работать только на пользователя. Create , update и delete не может добавить ничего нового для пользователя. Ваш класс Update может содержать только методы, которые работают с методами, уже определенными в классе sue.
TheLostMind 25 авг. 2014, в 08:02
0

@TheLostMind, если завтра я не хочу deleteUser, мне нужно пойти и внести изменения в UserOperations, что будет нарушением OCP. Если вместо этого у меня есть отдельный класс, мне не нужно трогать userOperations, чтобы не нарушать OCP, верно?
Manish 25 авг. 2014, в 08:08
0

Я не думаю, что твой пример лучший. Во-первых, я не думаю, что завтра избавление от deleteUser является разумным; вы, вероятно, захотите держаться за это. И это может указывать, какой дизайн лучше. Следующий SRP в этой степени раскручивает ООП. Если вы подумаете об этом, примеров занятий больше не будет. Они в основном перешли бы на одноразовые обертки.
ChiefTwoPencils 27 авг. 2014, в 09:57

Показать ещё 6 комментариев

Теги:

java

design

solid-principles

srp

1 ответ

Ещё вопросы

Шаблон фабрики или менеджера позволил бы вам использовать дизайн # 1, где управление жизненным циклом является исключительной ответственностью фабрики или менеджера. Конечно, это может быть дизайн # 2 ...;)
создавать , удалять и обновлять поведения (методы). Более целесообразно иметь один класс и один или несколько вспомогательных классов, поддерживающих его, вместо трех классов.
@MadProgrammer, так какой дизайн вы бы предложили?
@TheLostMind, но создание обновления и удаление - это три разные вещи, и они не связаны друг с другом, поэтому, когда я делаю создание, мне не нужно удалять и т. Д. Так что я чувствую, что они должны идти в разные классы.
Лично у меня был бы центральный менеджер, ответственный за весь жизненный цикл объекта, но это я ...
@Manish - Ваш дизайн косвенно связан. Вы должны работать только на пользователя. Create , update и delete не может добавить ничего нового для пользователя. Ваш класс Update может содержать только методы, которые работают с методами, уже определенными в классе sue.
@TheLostMind, если завтра я не хочу deleteUser, мне нужно пойти и внести изменения в UserOperations, что будет нарушением OCP. Если вместо этого у меня есть отдельный класс, мне не нужно трогать userOperations, чтобы не нарушать OCP, верно?
Я не думаю, что твой пример лучший. Во-первых, я не думаю, что завтра избавление от deleteUser является разумным; вы, вероятно, захотите держаться за это. И это может указывать, какой дизайн лучше. Следующий SRP в этой степени раскручивает ООП. Если вы подумаете об этом, примеров занятий больше не будет. Они в основном перешли бы на одноразовые обертки.

BartoszKP · Accepted Answer · 2014-08-27T07-33-00.000Z

Хорошо известна проблема определения ответственности. Роберт Мартин предлагает интерпретировать его так:

Принцип единой ответственности (SRP) гласит, что каждый программный модуль должен иметь одну и только одну причину изменения

а также (та же ссылка):

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

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

Мое мнение по этому поводу: дизайн № 2 в целом не идет. Вы должны создать класс «UserOperation», который имеет одну-единственную ответственность, а именно «управление пользователями». Не следует преувеличивать при создании разных классов для разных действий над объектом пользователя, поскольку все они отвечают за «пользователя». Это только в дополнение к правильному ответу выше.