Путаница с использованием объектно-ориентированного дизайна .. нужна помощь

Question

Допустим, у нас есть класс Order и класс OrderManagerService.

Класс заказа: [некоторые состояния и методы, которые воздействуют на состояние]

1. Item []
2. status

Класс OrderManagerService: [не имеет состояния.только следующие статические методы]

1. createOrder
2. getOrder

Вопрос: Допустим, мы используем реляционную БД сзади.Наша цель - обновить статус заказа.Ну а статус нужно обновлять в БД.Меня беспокоит, где поставить метод updateStatus.

1. Должен ли я затем вызвать OrderManagerService.getOrder, вызвать Order.updateStatus?
2. или создать новый метод как OrderManagerService.updateOrderStatus?

хорошо, 1-й вариант выглядит после инкапсуляции.Но лично мне это не нравится, так как мы можем в конечном итоге вызвать слой DAO из объектов сущности [возможно, это может быть хорошо].Хотите знать, что будет правильным выбором дизайна и почему?любая помощь очень ценится.

Answer 1

Вариант 2 - создать новый метод как OrderManagerService.updateOrderStatus?

Почему?

Ваш уровень обслуживания должен инкапсулировать логическую бизнес-единицу работы, и в вашем случае UOW равен

1. получить заказ из БД
2. обновить статус объекта
3. сохранить изменения

и вы бы разграничили updateOrderStatus (...) с транзакцией. и служба по-прежнему без гражданства.

Answer 2

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

Наличие всехповедение, содержащееся в Сервисах, можно сравнить с Анемичной Доменной Моделью , в которой вам решать, будет ли это плохо или нет - по этому поводу много споров.

Answer 3

Я думаю, что OrderManagerService должен иметь массив элементов класса Order. Таким образом, вы можете перебирать каждый элемент и обновлять статус там. Или, если вы ищете доступ к отдельной позиции заказа, перейдите непосредственно к ней через класс Order и обновите ее там.

В любом случае с вашей текущей настройкой updateStatus() должно быть в классе Order.

Answer 4

Как насчет паттерна наблюдателя ?

updateStatus () будет в классе Order, что будет наблюдаться классом OrderManagerService.

Каждый раз, когда вы меняете статус (или еще что-нибудь), Менеджер будет видеть его и при необходимости выполнять некоторые действия (например, обновлять статус в БД).

Менеджер может связываться с Order при создании экземпляра и возврате его в метод getOrder ().

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

Answer 5

Почему существует отдельный класс OrderManagerService?Я бы включил все эти методы в Order.

(Возможно, это не теоретически правильный или не совместимый с бандой шаблон проектирования, но мне было все равно, потому что он имел бы больше смысла.)