Определение ответственности класса - PullRequest
0 голосов
/ 25 мая 2018

Я знаю, что это серьезный вопрос.Однако это часто возникает на работе.При создании методов часто трудно понять, какой класс должен отвечать.

Например,

bool result = ProductService.CategoryHasSoldOutOfProducts(int categoryId)

против

bool result = CategoryService.CategoryHasSoldOutOfProducts(int categoryId)

По моему мнению, CategoryService должен нести ответственность, так как метод принимает categoryId и относится к Category .

Другие в моей работе говорят, что ProductService должен нести ответственность за то, как работает метод, если Продукты распроданы.

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

Спасибо

Ответы [ 2 ]

0 голосов
/ 26 мая 2018

Поскольку вы спрашиваете мнения, вот мое: (Отказ от ответственности: Это, вероятно, то, что вы не можете легко реализовать в деловом мире)

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

Кроме того, оно очень общее.Это как называть класс «Менеджер».Вы можете поместить в него все, что угодно, и этот класс может вырасти и иметь сотни функций.

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

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

0 голосов
/ 25 мая 2018

Отказ от ответственности - это чисто ИМХО ответ.Я отвечаю на это в духе конструктивного мозгового штурма.

Исходя из ОП, кажется, что связь между категорией и продуктом является необязательной для многих: Категория (0..1) <--------> (*) Product.

В случае реализации это означает, что сущность Category, вероятно, имеет Контейнер продуктов, а сущность Product имеет ссылку на Category, которая может быть NULL.

В этом случае я согласен с решением о передаче CategoryHasSoldOutOfProducts под ответственность субъекта Category.Название метода явно подразумевает, что сущность Category должна отвечать за информирование своего пользователя API о состоянии своих продуктов.

Однако существует и другая опция: класс / сущность ассоциации .Мотивация этой сущности состоит в том, чтобы описать отношения между двумя другими сущностями.

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

ProductContainment не будет иметь внутреннего состояния и будет содержать функции, которые предоставляются с сущностями категории и / или продукта в качестве параметров.Тогда субъект ассоциации должен обеспечить реализацию функций, которые связаны с тем, как Категория и Продукт связаны друг с другом.

Если вы в конечном итоге используете ProductContainment - тогда CategoryHasSoldOutOfProducts должна быть одной из его функций.

...