Що означає "низький рівень зв'язку та високий рівень згуртованості"

У мене проблеми з розумінням твердження low in coupling and high in cohesion. Я дуже багато читав про це, але все ще важко зрозуміти.

Наскільки я розумію, це High cohesionозначає, що у нас повинні бути класи, спеціалізовані для виконання певної функції. Сподіваюся, що це правильно? Як і клас валідації кредитної картки, який спеціалізується лише на валідації кредитних карт.

І досі не розумію, що означає низьке зчеплення?

Я вважаю, що це:

Згуртованість означає ступінь, до якого елементи модуля / класу належать разом; пропонується, щоб відповідний код був близький один до одного, тому ми повинні прагнути до високої згуртованості та зв'язати весь пов'язаний код разом якомога ближче. Це пов'язано з елементами в модулі / класі.

З'єднання відноситься до того, наскільки різні модулі / класи залежать один від одного, пропонується, щоб усі модулі були настільки незалежними, наскільки це можливо, тому низьке з'єднання. Це пов'язано з елементами серед різних модулів / класів.

Для візуалізації всієї картини буде корисно:

Скріншот був зроблений із Coursera .

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

Один із способів розгляду згуртованості з точки зору ОО - це, якщо методи в класі використовують будь-який із приватних атрибутів.

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

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

Вільне з'єднання - це метод з'єднання компонентів у системі чи мережі таким чином, що ці компоненти залежать один від одного в мінімальній мірі практично можливої ​​...

Я написав про це запис у блозі . Він обговорює все це дуже докладно, з прикладами тощо. Він також пояснює переваги, чому слід дотримуватися цих принципів.

У дизайні програмного забезпечення висока згуртованість означає, що клас повинен дуже добре робити одне і одне. Висока згуртованість тісно пов'язана з принципом єдиної відповідальності .

Низька муфта припускає, що клас повинен мати найменші можливі залежності. Також залежності, які повинні існувати, повинні бути слабкими залежностями - віддайте перевагу залежності від інтерфейсу, а не залежності від конкретного класу, або віддайте перевагу складу над успадкуванням.

Висока згуртованість і низьке з'єднання дають нам кращий дизайн, який простіший у обслуговуванні.

Коротка і чітка відповідь

• Висока згуртованість : елементи в одному класі / модулі повинні функціонально належати разом і робити одну конкретну річ.
• Вільне з'єднання : серед різних класів / модулів повинна бути мінімальна залежність.

Низьке з'єднання знаходиться в розрізі двох або багатьох модулів. Якщо зміна одного модуля призводить до багатьох змін в іншому модулі, тоді, як кажуть, вони сильно пов'язані. Тут допомагає програмування на основі інтерфейсу. Будь-яка зміна всередині модуля не вплине на інший модуль, оскільки інтерфейс (середнє значення взаємодії) між ними не змінився.

Висока згуртованість. Складайте подібні речі разом. Отже, клас повинен мати метод або поведінку, щоб виконувати пов'язані з цим завдання. Просто навести перебільшений поганий приклад: реалізація інтерфейсу List не повинна мати операції, пов’язану зі String. Клас String повинен мати методи, поля, які є релевантними для String, і так само, реалізація List повинна мати відповідні речі.

Сподіваюся, що це допомагає.

Короткий короткий і низький зв'язок, як я зрозумів, це означає, що компоненти можна замінити, не впливаючи на належне функціонування системи. В основному, модулюйте вашу систему у функціонуючі компоненти, які можна оновлювати окремо, не порушуючи систему

У вас смарт-телефон? Є одне велике додаток або багато маленьких? Чи відповідає одна програма на іншу? Чи можете ви використовувати один додаток під час встановлення, оновлення та / або видалення іншого? Те, що кожен додаток є автономним, - це висока згуртованість. Те, що кожне додаток не залежить від інших, - це низьке з'єднання. DevOps надає перевагу цій архітектурі, оскільки це означає, що ви можете робити дискретні безперервні розгортання, не порушуючи всю систему.

Спадкування або узагальнення є прикладом високої зв’язки (тобто високої взаємозалежності). Що я мав на увазі під цим, це те, що у спадок часто батьківський клас визначає базові функціональні можливості, які використовуються його дочірнім класом, а зміна методів батьківського класу безпосередньо впливає на його дочірні класи. Звідси можна сказати, що між класами існує більша ступінь взаємозалежності.

Реалізація або використання інтерфейсу є прикладом високої згуртованості (тобто низької взаємозалежності). Це означає, що інтерфейс, що висуває контракт для будь-якого класу, який його реалізує, але кожен клас має право реалізовувати методи, оголошені в інтерфейсі, по-своєму, а зміни методу, оголошеного в одному класі, не впливають на будь-який інший клас.

Згуртованість - наскільки тісно пов'язане все між собою.
З’єднання - як все пов’язано між собою.

Візьмемо для прикладу - Ми хочемо сконструювати автомобіль, що керує самостійно

(1) Нам потрібен мотор, щоб справно працювати.

(2) Нам потрібна машина, щоб їхати самостійно.

Усі класи та функції (1) запускають двигун і змушують його працювати добре разом, але не допомагають керувати автомобілем. Отже, ми кладемо ці класи за контролер двигуна.

Всі класи та функції в (2) чудово працюють, щоб зробити автомобіль рульовим, прискореним та гальмуючим. Вони не допомагають авто заводитись і не відправляють бензин в поршні. Тому ми розміщуємо ці класи за власним контролером водіння.

Ці контролери використовуються для зв'язку з усіма наявними класами та функціями. Потім контролери спілкуються лише один з одним. Це означає, що я не можу викликати функцію класу поршня з класу педалей газу, щоб змусити машину їхати швидше.

Клас педалей повинен попросити керуючий керуючим поговорити з контролером двигуна, який потім говорить класу поршня йти швидше. Це дає змогу програмістам знаходити проблеми та дозволяє нам поєднувати великі програми, не турбуючись. Це тому, що код працював за контролером.

Низька зв'язаність та висока згуртованість є рекомендованим явищем.

З'єднання означає, наскільки різні модулі взаємозалежні і як інші модулі впливають на зміну деякої / значної функціональності модуля. Підкреслюється низька зв'язок, оскільки залежність повинна підтримуватися низькою, щоб в інших модулях були внесені найменші / незначні зміни.

Приклад може бути корисним. Уявіть систему, яка генерує дані та розміщує їх у сховищі даних, або файл на диску чи база даних.

Високої згуртованості можна досягти, відокремивши код сховища даних від коду виробництва даних. (і фактично відділення дискового сховища від сховища бази даних).

Низьке з'єднання можна досягти, переконавшись, що при виробництві даних немає зайвих знань про сховище даних (наприклад, не запитує у сховищі даних про назви файлів або з'єднання db).

Ось відповідь з дещо абстрактного, теоретичного кута графіка:

Давайте спростимо проблему, лише переглянувши (спрямовані) графіки залежності між стаціонарними об'єктами.

Надзвичайно просту відповідь можна проілюструвати, розглядаючи два обмежуючих випадки графіків залежності:

Перший обмежуючий випадок : графіки кластера .

Графік кластерів - це найдосконаліша реалізація графіка залежності високої згуртованості та низької зв'язку (з урахуванням набору розмірів кластерів).

Залежність між кластерами максимальна (повністю пов'язана), а міжкластерна залежність мінімальна (нуль).

Це абстрактна ілюстрація відповіді в одному з обмежуючих випадків .

Другий обмежуючий випадок - це повністю пов'язаний графік, де все залежить від усього.

Реальність десь посередині, чим ближче до кластерного графіка, тим краще, на моє скромне розуміння.

З іншого погляду : при перегляді графіка спрямованої залежності в ідеалі він повинен бути ациклічним, якщо не, то цикли утворюють найменші кластери / компоненти.

Один крок вгору / вниз по ієрархії відповідає "одному екземпляру" нещільної зв'язку, щільної згуртованості в програмному забезпеченні, але можна розглянути цей принцип вільної зв'язку / щільної згуртованості як повторювані явища на різних глибинах ациклічного спрямованого графіка (або на одне з його насаджених дерев).

Такий розклад системи на ієрархію допомагає перемогти експоненціальну складність (скажімо, кожен кластер має 10 елементів). Тоді в 6 шарів це вже 1 мільйон об’єктів:

10 кластерів утворюють 1 суперкластер, 10 суперкластери утворюють 1 гіперкластер і так далі ... без концепції жорсткої згуртованості, нещільної зв'язку, така ієрархічна архітектура була б неможливою.

Отже, це може бути справжньою важливістю цієї історії, а не лише високої низької згуртованості, пов'язаної лише в два шари. Справжня важливість стає зрозумілою при розгляді абстракцій вищого рівня та їх взаємодій.

Я думаю, у вас є багато червоних визначень, але у випадку, якщо ви все ще сумніваєтесь, або У випадку, якщо ви новачок у програмуванні і хочете заглибитись у це, тоді я запропоную вам подивитися це відео, https://youtu.be/HpJTGW9AwX0 Це просто посилання, щоб отримати більше інформації про поліморфізм ... Сподіваюся, ви краще зрозумієте це

Низька муфта: - Тримати це буде дуже просто. Якщо ви змінюєте модуль, як він впливає на інші модулі.

Приклад: - Якщо ваш сервісний API виставлений як JAR, будь-яка зміна підпису методу порушить виклик API (зв'язок High / Tight).

Якщо ваш модуль та інший модуль спілкуються через повідомлення про асинхронізацію. Поки ви отримуєте повідомлення, підпис зміни методу буде локальним для вашого модуля (Низьке з'єднання).

Поза курсом, якщо є зміна формату повідомлення, для виклику клієнта потрібно буде внести деякі зміни.