Принудительно применять бизнес-правила уровня обслуживания к изменениям свойств объекта или скрывать свойство объекта от клиентов, но не от службы?

Question

Допустим, у меня есть класс Customer, у которого есть свойство customerType.

У меня есть другой класс, который называется что-то вроде SpecialContract, у которого есть Customer и некоторые другие свойства.

Если customer.customerType == SPECIAL, то существует SpecialContract, который имеет ссылку на этого конкретного клиента.

Теперь я понимаю, что это немного нелепо, но я не хочу поддерживать отношения от Клиента до SpecialContract по нескольким причинам, одна из которых заключается в том, что большую часть времени при работе с Клиентами мы не нужно загружать SpecialContracts и все другие данные, связанные с SpecialContracts. Однако я всегда хочу знать, есть ли у Customer SpecialContract, и это достигается с помощью его свойства customerType.

Хорошо, вот сложная часть. Я не хочу, чтобы клиент мог устанавливать customerType, потому что простое выполнение не удалит SpecialContract, который применяется к клиенту, что потребуется. Я бы предпочел заставить клиента вызывать метод службы для удаления SpecialContract, который также установил бы для customerType значение NOTSPECIAL для всех в одной транзакции.

Как я могу скрыть установщик customerType от клиентов, но по-прежнему предоставлять его моему классу уровня обслуживания, который будет отвечать за установку правильного значения, а также за удаление SpecialContract? Мой класс обслуживания не входит в тот же пакет, что и класс Customer.

Answer 1

Я бы не стал прятать сеттер от вашего клиента. Скорее, если клиент изменяет состояние клиента и пытается его сохранить, следует выполнить проверку, чтобы определить, было ли изменено значение SpecialContract / customerType, и, возможно, вызвать исключение, если оно было. Затем вы можете создать метод, на который вы ссылались ранее, который может соответствующим образом обновить SpecialContract / customerType.

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

Answer 2

Может быть, здесь может быть полезным аспектно-ориентированное программирование. Вы можете перехватить вызов Клиента, который передает Контракт, получить рекомендацию перед методом создать экземпляр подкласса Специального контракта при определенных условиях и передать его методу. Вам просто нужно спроектировать иерархию контрактов так, чтобы она строго соблюдала принцип подстановки Лискова.

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

Answer 3

Вы можете создать Interface, который реализует Customer, и передать экземпляр этого Interface клиенту. Этот Interface не предоставит клиенту модификатор contentType. Ваша служба будет иметь дело с полноценными Customer объектами и может использовать модификатор setContentType, как определено в Class.

Answer 4

Почему бы не выполнить сканирование системы при запуске, ища все Customer с ссылками в SpecialContract с, сохраняя список всех этих Customer где-то в частном порядке, скажем, на уровне обслуживания где-нибудь? * * 1004