Выберите методы класса, когда есть делегирование ООП

Вкратце мои ответы:

1. Нет, инкапсуляция не нарушена.
2. То, что Person может менять цвет, уже дано Ассоциацией.
3. Действия Person могут включать вызов собственных операций, но возможны и многие другие действия.

Дополнительные пояснения:

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

пункт 2: когда класс имеет доступ к экземплярам другого класса, он потенциально может использовать все свои общедоступные функции. В вашем примере есть Ассоциация между Person и House. Следовательно, Person может вызывать changeColor, но не обязан это делать. В более полной модели House может иметь гораздо больше функций, и не все из них могут быть предназначены для использования Person. В этом случае полезно определить интерфейс для конкретного клиента, содержащий только функции, необходимые классу Person. Затем ассоциация будет направлена ​​на этот интерфейс, который, в свою очередь, реализуется классом House. Класс Person по-прежнему технически не требуется для использования всех функций интерфейса. Тем не менее, я бы рассматривал ассоциацию с интерфейсом как явное указание на намерение разработчиков моделей, что все функции в конечном итоге будут использованы.

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

В полной дизайнерской модели поведение класса Person будет определено каким-то образом. Это может быть с Activity. В этой Деятельности может быть много Действий. Один может быть CallOperationAction, который звонит changeColor. Это будет явная спецификация того, как класс Person использует класс House. Он также может вызвать свою собственную операцию changeHouseColor, которая, в свою очередь, может быть указана с помощью действия.

В UML определено множество других действий, таких как ReadStructuralFeatureAction или CreateObjectAction. Они используются не так часто, так как нет особого смысла моделировать на таком уровне детализации. Тем не менее, я думаю, что знать о них полезно, чтобы лучше понять, как связаны Операции и Действия.

В общем, ничего плохого и в person.changeHouseColor(color), и в person.getHouse().changeColor(color) нет. Какой подход лучше, зависит от вашего домена.

Мы можем сказать, что person.getHouse().changeColor(color) нарушает Закон Деметры (LOD) или принцип наименьшего знания. Идея состоит в том, чтобы иметь знания только о "близко" связанных классах. Классы, имеющие экземпляр Person, не должны зависеть от его внутренней структуры и вместо этого вызывать только методы Person: person.changeHouseColor(color).

Этот подход имеет как преимущества, так и недостатки. Основным преимуществом является возможность изменения внутренней структуры классов (Person class) без переделки их клиентов.

Это определенно не нарушает парадигму инкапсуляции. Ограничение прямого доступа к некоторым компонентам объекта можно даже рассматривать как лучшую инкапсуляцию.

Недостатком является необходимость написания множества методов-оболочек для передачи вызовов делегатам.

Но если вы хотите показать, что изменить House цвет может только человек, то модель, вероятно, не идеальна. Потому что любой класс, имеющий доступ к экземпляру House, может напрямую вызывать house.changeColor(color), даже не имея экземпляра Person. И будет экземпляр House по крайней мере в методе, который его создает:

House house = new House(Color.WHITE);
Person person = new Person(house);
person.changeHouseColor(Color.ORANGE); //OK
house.changeColor(Color.WHITE); //should we allow it?

Этот аспект во многом зависит от домена. Важно определить агрегаты в вашем домене.

В этом сценарии есть два основных варианта:

• добавить метод getHouse() к Person, который требует, чтобы клиентский код соблюдал это и использовал интерфейс House соответствующим образом, или
• как и раньше, скройте делегата (House) с помощью дополнительного метода для Person.

Это классический компромисс при проектировании, который обсуждался в книге Фаулера Рефакторинг: улучшение дизайна существующего кода в качестве Скрыть делегат рефакторинг. Чтобы ответить на ваш вопрос, в дополнение к преимуществам документации, которые вы упомянули, скрытие делегата фактически увеличивает инкапсуляцию:

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

Короче говоря

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

Плюсы - Когда это делать?

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

Но это не единственный способ распределить обязанности между классами, и есть много причин оставить дизайн более открытым, например: Что, если Person не покрасит свой дом сама, а попросит Painer сделать эту работу? от ее имени? Что, если бы, гипотетически, мэр деревни имел право принимать решение об изменении цвета и посылал своих маляров через деревню?

Минусы - по возможности избегайте!

В вашей конструкции есть большой недостаток. Это связано с принципом единой ответственности (SRP):