Що таке розв'язка і до яких сфер розвитку можна застосувати? [зачинено]

Нещодавно я помітив розв'язку як тему в питанні, і хочу знати, що це таке і де воно може застосовуватися.

Під "куди це можна застосувати", я маю на увазі:

Це актуально лише там, де задіяні компільовані мови, такі як C та Java?

Чи варто мені знати / вивчати це як веб-розробник?

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

Коли клас використовує інший клас або спілкується з ним, кажуть, що він "залежить" від цього класу, і ці класи "пов'язані". Принаймні одна з них «знає» про іншу.

Ідея полягає в тому, що ми повинні намагатися зберегти зв’язок між класами в наших системах якомога більш "вільним": отже, "вільне з'єднання" або іноді "розв'язка" (хоча в перекладі з англійської мови "розв'язка" означатиме "взагалі немає зв'язку", люди часто використовують його для позначення «вільної зв'язку» між сутностями).

Отже: що таке практичне сполучення та сильне сполучення на практиці, і чому ми маємо робити об'єкти вільно пов'язаними?

З'єднання описує ступінь залежності однієї сутності до іншої сутності. Часто класи або предмети.

Коли ClassA сильно залежить від ClassB, шанси вплинути на ClassA при зміні ClassB високі. Це сильна зв’язок.

Однак якщо ClassA залежить від ClassB, то шанси зміни будь-якого класу зміни на код ClassB низькі. Це нещільне з’єднання або "роз'єднані" відносини.

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

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

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

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

Сильна зв'язок зазвичай виникає, коли суб'єкт А занадто багато знає про сутність B. Якщо суб'єкт А робить занадто багато припущень щодо того, як господарство B функціонує або як він побудований, то існує високий ризик, що зміна сутності B вплине на сутність A. Це це тому, що одне з припущень щодо сутності B зараз неправильне.

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

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

Однак якщо всі припущення, які ви як водій ви зробили щодо автомобілів, такі: A- у них є кермо, а B- у них педалі гальм і газів, то зміни в машині на вас не вплинуть, якщо ваші кілька припущень. залишайтеся правильними. Це нещільна муфта.

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

Так, наприклад, якщо ви визначення класу автомобіля, його інтерфейс (загальні методи), ймовірно , буде drive(), stop(), steerLeft(), steerRight(), getSpeed(). Це методи, які інші об'єкти можуть використовувати на об'єктах автомобіля.

Всі інші деталі класу "Автомобіль": як працює двигун, вид палива, яке він використовує тощо, приховані від інших класів - щоб не допустити їх занадто багато про автомобіль.

Момент класу A занадто багато знає про клас B: у нас сильно пов'язані відносини, коли клас A занадто залежний від класу B, а зміна класу B, ймовірно, вплине на клас А. Зростання системи важко розширюється та підтримується.

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

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

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

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

Це, мабуть, найпоширеніший тип зчеплення, що зустрічається в природі:

//Inside a class meant to display info for a particular Facebook user.
void DisplayFriends(FacebookUser user, FacebookClient client)
{
     Friend[] = (Friend[])client.GetConnection().ExecuteCommandForResult("getFriends:" + user.Name);
     ...
}

Тут DisplayFriends непотрібно вручну працювати з підключенням за клієнтом Facebook, щоб отримати те, що йому потрібно. DisplayFriendsКлас поєднаний з обома FacebookClientі Connection. Якщо FacebookClient раптом змінить тип зв’язку, який він використовує, додаток більше не зможе завести друзів у Facebook. Ми можемо зняти зв'язок між класом DisplayFriends та Connection, попросивши FacebookClient надати те, що нам потрібно.

//Inside a class meant to display info for a particular Facebook user.
void DisplayFriends(FacebookUser user, FacebookClient client)
{
     Friend[] = client.GetFriends(user);
     ...
}

Зараз нас дуже не хвилює, як FacebookClient отримує наших друзів. Все, що нас дійсно хвилює, - це те, що вони їх отримують. Будь-які зміни, внесені до його внутрішньої поведінки, не зашкодять нашому власному класу.

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

Закон Деметера для функцій вимагає, щоб метод m об’єкта O міг посилатися лише на методи таких типів об'єктів:

• O себе
• m параметри
• Будь-які об'єкти, створені / створені в межах m
• O об'єкти прямого компонента
• Глобальна змінна, доступна O, в області m

Оскільки я згадував про тимчасову зв'язок на початку відповіді, я коротко опишу це.

Тимчасове з'єднання, як правило, враховується при розробці програм, які паралельно виконують алгоритми. Розглянемо два виконуваних одиниці (будь то фактичні вказівки, методи або все, що ви хочете вважати одиницею), A і B. Ми говоримо, що A тимчасово пов'язане з B, якщо B повинно бути виконано до початку A. Якщо A не тимчасово пов'язане з B, A і B можуть бути виконані одночасно. Створіть для цього власний приклад: подумайте про звичні речі, які ви робите у своєму щоденному житті. Чи є дві речі, які ви робите одна за одною, але ви могли робити це одночасно?

Нарешті, щоб відповісти на ваш останній шматочок:

Чи варто мені знати / вивчати це як веб-розробник?

Так. Наприклад, одна з найпопулярніших моделей дизайну для веб-розробки (MVC) - це все про розв'язку.

Інші відповіді добре допомагають описати, що таке розв'язка. Я хотів обговорити ваше останнє питання.

Чи варто мені знати / вивчати це як веб-розробник?

Відповідь - це рішуче "так". Не має значення, який ти розробник. Ви можете бути веб-розробником або розробником вбудованих систем.

Скажімо, у вас є клас, який генерує власні URL-адреси, розміщені на вашій веб-сторінці. Можливо, вам сподобається, щоб клас записував URL-адреси безпосередньо на сторінку, розміщуючи їх у href тегу. Спочатку це може здатися простішим. Але що станеться, коли вам потрібно внести зміни, щоб розмістити посилання в електронній пошті та надіслати їх користувачеві? Ваш поточний код не працює, оскільки ваш генератор URL-адрес щільно пов'язаний з веб-рамкою, яку ви використовуєте.

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

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