Вільна муфта в об'єктно-орієнтованому дизайні

Я намагаюся навчитися GRASP, і я виявив, що це пояснено ( тут, на сторінці 3 ) про низьке з'єднання, і я був дуже здивований, коли виявив це:

Розглянемо метод addTrackдля Albumкласу, два можливі методи:

addTrack( Track t )

і

addTrack( int no, String title, double duration )

Який метод зменшує з'єднання? Другий - так, оскільки клас, що використовує клас "Альбом", не повинен знати клас "Трек". Загалом, параметри методів повинні використовувати базові типи (int, char ...) та класи з пакетів java. *

Я схильний погодитися з цим; Я вважаю, що addTrack(Track t)це краще, ніж addTrack(int no, String title, double duration)через різні причини:

1. Завжди краще, щоб метод мав якомога менше параметрів (згідно Чистого кодексу дядька Боба жодного або одного, бажано, 2 в деяких випадках і 3 в особливих випадках; більше 3 потребує рефакторингу - це звичайно рекомендації, а не правила). .

2. Якщо addTrackце метод інтерфейсу, і вимоги потребують, щоб у a було Trackмати більше інформації (скажімо, рік чи жанр), тоді інтерфейс потрібно змінити, щоб метод підтримував інший параметр.

3. Інкапсуляція порушена; якщо addTrackв інтерфейсі, то він не повинен знати внутрішніх даних Track.

4. Це насправді більше поєднано по-другому, з багатьма параметрами. Припустимо, noпараметр потрібно змінити з intна, longтому що їх більше, ніж MAX_INTтреків (або з будь-якої причини); то і те, Trackі метод потрібно змінити, тоді як якщо методом було б addTrack(Track track)лише те, Trackбуло б змінено.

Всі 4 аргументи насправді пов’язані між собою, а деякі з них є наслідками з боку інших.

Який підхід кращий?

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

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

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

Наприклад, розгляньте кнопку "Додати до списку відтворення" та Playlistоб'єкт. Введення Trackоб'єкта може розглядатися як збільшення з'єднання, якщо врахувати лише ці два об'єкти. Тепер у вас є три взаємозалежні класи замість двох. Однак це не є повнотою вашої системи. Вам також потрібно імпортувати доріжку, відтворити композицію, показати доріжку тощо. Додавання ще одного класу до цієї суміші незначно.

Тепер розглянемо необхідність додавати підтримку для відтворення треків через мережу, а не лише локально. Вам просто потрібно створити NetworkTrackоб’єкт, який відповідає одному інтерфейсу. Без Trackоб'єкта вам доведеться створювати функції скрізь:

addNetworkTrack(int no, string title, double duration, URL location)

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

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

Моя рекомендація:

Використовуйте

addTrack( ITrack t )

але будьте впевнені, що ITrackце інтерфейс, а не конкретний клас.

Альбом не знає внутрішньої частини ITrackвиконавців. Це лише в поєднанні з контрактом, визначеним ITrack.

Я думаю, що це рішення, яке генерує найменшу кількість зчеплення.

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

Перший приклад методу передбачає, що Доріжка отримується миттєво поза класом Альбом, тому, принаймні, можна припустити, що інстанція класу Трек не пов'язана з класом Альбом.

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

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

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

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

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

Щоб вирішити проблему, вам потрібно буде розділити Trackїї компоненти інтерфейсу та її логічні компоненти, створивши два окремих класи. Абоненту Trackстає легкий клас, який призначений для зберігання інформації та пропонування незначних оптимізацій (обчислені дані та / або значення за замовчуванням). Всередині Albumви б використовували клас з іменем TrackDAOдля виконання важкого підйому, пов'язаного із збереженням інформації Trackв базі даних.

Звичайно, це лише приклад. Я впевнений, що це зовсім не ваш випадок, тому не соромтесь користуватися без Trackпровини. Просто пам’ятайте, щоб мати на увазі абонента під час створення класів та створювати інтерфейси, коли це потрібно.

Обидва вірні

addTrack( Track t ) 

це краще (як ви вже аргументовано) , а

addTrack( int no, String title, double duration ) 

є менш сполученим, оскільки код, який використовує addTrack, не повинен знати, що існує Trackклас. Трек можна перейменувати, наприклад, без необхідності оновлення коду виклику.

Поки ви говорите про більш читабельний / підтримуваний код, у статті йдеться про з'єднання . Менш пов'язаний код не обов’язково простіше реалізувати та зрозуміти.

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

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

Якщо піти на крок далі, якби очікували, що трек буде замінений чимось, що зробив ту саму роботу краще, можливо, буде потрібний інтерфейс, що визначає необхідну функціональність, ITrack. Це може призвести до різних реалізацій, таких як "AnalogTrack", "CdTrack" та "Mp3Track", що надало додаткову інформацію, більш конкретну для цих форматів, при цьому надаючи базову експозицію даних ITrack, що концептуально являє собою "трек"; кінцева пісня з аудіо. Track може подібним чином бути абстрактним базовим класом, але для цього потрібно завжди бажати використовувати реалізацію, властиву Track; повторно виконати його як BetterTrack, і тепер вам доведеться змінити очікувані параметри.

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