Сцепление/сцепление

Question

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

Answer 1

Я могу рекомендовать Алана и книга Джеймса Design Patterns explained -- A new perspective on object-oriented design (ISBN-13: 978-0321247148):

это большая книга о имеет-а и есть- decissions, в том числе сцепления и сцепления в объектно-ориентированном проектировании.

Answer 2

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

Существует действительно только 1 действительно большая вещь, которую я бы изменил в вашем коде. Я хотел бы рассмотреть вопрос о том, что называется Command Pattern. Информация об этом не составит труда найти ни в Интернете, ни в книге GoF.

Основная идея заключается в том, что каждая из ваших команд «add child», «add parent» становится отдельным классом. Логика для одной команды заключена в один небольшой класс, который легко тестировать и модифицировать. Затем этот класс должен быть «выполнен» для выполнения работы из вашего основного класса. Таким образом, ваш основной класс должен иметь дело с разбором командной строки и может потерять большую часть своих знаний о FamilyTree. Он просто должен знать, какие карты командной строки вводят классы команд и отбрасывают их.

Это мои 2 цента.

Answer 3

Короче:

Сплоченность в программной инженерии, как и в реальной жизни, сколько элементы, состоящие в целом (в нашем случае, скажем, класс), можно сказать, что они на самом деле принадлежат вместе. Таким образом, это показатель того, насколько сильно связаны каждая функциональность, выраженная исходным кодом программного модуля.

Один из способов взглянуть на сплоченность с точки зрения OO - это если методы в классе используют какие-либо частные атрибуты.

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

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

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

В длиной:

I wrote a blog post about this. Он подробно обсуждает все это с примерами и т. Д. Это также объясняет преимущества того, почему вы должны следовать этим принципам. Я думаю, что это могло бы помочь ...

Answer 4

Сцепление определяет степень зависимости каждого компонента от других компонентов системы. Учитывая два компонента A и B, сколько кода в B должно измениться, если A изменится. Сплоченность определяет меру того, насколько когерентны или сильно связаны различные функции одного программного компонента. Это относится к тому, что делает класс. Низкая сплоченность означает, что класс выполняет множество действий и не фокусируется на том, что он должен делать. Тогда высокая сплоченность означает, что класс ориентирован на то, что он должен делать, т. Е. Только методы, связанные с намерением класса. Примечание: Хорошие API-интерфейсы демонстрируют свободную связь и высокую степень сцепления. Особо отвратительной формой жесткой связи, которую всегда следует избегать, является наличие двух компонентов, которые прямо или косвенно зависят друг от друга, то есть цикл зависимости или круговая зависимость. Подробная информация в нижеуказанной ссылке http://softwarematerial.blogspot.sg/2015/12/coupling-and-cohesion.html