ОО Дизайн Вопрос

Question

Нужны мнения по этому поводу:

Я разбил различные обязанности на отдельные объекты. Однако многие из этих объектов имеют зависимости друг от друга. Все эти объекты привязаны к интерфейсам, поэтому я не привязан к реализации. Я обеспокоен зависимостями между объектами и возможностью круговых зависимостей. Это признак плохого дизайна? Что сделали другие люди, чтобы разделить обязанности и управлять зависимостями? Спасибо.

Answer 1

Важно то, что объектные модели имеют Низкая связь и Высокая когезия . Это означает, что вещи должны зависеть от других вещей только тогда, когда они должны (Сцепление), и что они должны делать одно и только одно (очень хорошо) (Сплоченность). Не существует простого ответа о том, когда принимать эти решения, кроме опыта (что означает обучение на ошибках), будет вашим основным драйвером. Существует множество шаблонов проектирования для адресации сопряжения ( Фасад, Композит, Памятка, Декоратор и т. Д. ). Сплоченность - это обычно просто упражнение по рефакторингу для перемещения предметов в классы или из него, когда вы начинаете с ними работать.

Answer 2

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

Answer 3

Как еще один читатель указал на то, что вы хотите, чтобы ваши классы имели низкое сцепление и высокое сцепление. Если у ваших классов есть риск циклических зависимостей, это звучит так, как будто у вас плохой запах кода.

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

Answer 4

Хорошо, вы можете внедрить эти зависимости .... Если foo зависит от реализации bar, тогда заставьте его конструктор требовать экземпляр bar в качестве аргумента или установить его через метод setter.