Изменяемые объекты значения / состояние совместного использования (и пивоварение!)

Question

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

Я пытаюсь написать программное обеспечение для пивоварения. В пивоварении иногда необходимо заменить определенное разнообразие хмеля тем, что требуется в рецепте. Например, у вас может быть рецепт, который требует хмеля «Амарилло», но все, что вы можете получить, это «Каскад», который имеет достаточно похожий аромат для замены; хмель имеет количество альфа-кислоты (на данную массу), и соотношение между двумя хмелями является частью формулы замещения. Я пытаюсь смоделировать это (правильно) в моей программе.

Мой первоначальный вариант - иметь два объекта. Один HopVariety, который содержит общую описательную информацию о множестве прыжков, и один HopIngredient, который является конкретным экземпляром HopVariety и также включает количество, используемое в данном рецепте. HopIngredient должен знать о своем разнообразии, а HopVariety должен знать, что можно использовать вместо него (не все замены симметричны). Это похоже на хороший ООП.

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

Итак, вариант B: ввести сортовую коллекцию сортов и свободно объединить ингредиенты и разновидности по имени или уникальному идентификатору. И затем VarietySubstitutionManager, так что сорта не содержат ссылок на другие сорта, только на их идентификаторы. Это идет вразрез с тем, что я хочу сделать, потому что наличие ссылки на объект разнообразия имеет интуитивный смысл, и теперь я представляю то, что кажется чрезмерным уровнем абстракции, а также отделяю функции от данных.

Итак, как мне правильно распределить состояние среди того, что составляет конкретные экземпляры? Какой правильный или, по крайней мере, самый разумный способ решить проблему?

Answer 1

Вы уверены, что HopVariety должен быть объектом значения? Для меня это звучит как сущность - сорт хмеля «Амарилло» один и только один, поэтому он должен быть уникально идентифицируемым объектом. Точно так же, как «Тони Вустер» только один (ну, не совсем, но вы поняли;))

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

Кстати: Книга DDD содержит множество примеров ситуаций, подобных вашей, и способов их решения.

Answer 2

Насколько сильно вы хотите избежать мутации объектов с несколькими ссылками?

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

В конце этой дороги лежит монада ввода / вывода. Как далеко вы хотите пойти в этом направлении?

С функциональным языком, который допускает побочные эффекты мутации, например, S / ML и т. Д., Вы можете сохранить чистоту своего сорта и ингредиентов и хранить функции, которые возвращают текущий объект сорта из последней коллекции сорта, хранящийся в одной изменяемой ссылочной ячейке. Может показаться, что это разумный способ разделить разницу.

Answer 3

Я думаю, что ваш выбор либо

• имеет функцию «обновить разнообразие», чтобы просмотреть существующий граф объектов и создать новый с обновленными ингредиентами, или
• продолжайте использовать изменчивость

Имея под рукой информацию, мне не ясно, что лучше для вашей ситуации.