Чи можна застосовувати DRY без збільшення зчеплення?

Припустимо, у нас є програмний модуль A, який реалізує функцію F. Інший модуль B реалізує ту ж функцію, що і F '.

Існує кілька способів позбутися від дублюючого коду:

1. Нехай A використовує F 'від B.
2. Нехай B використовує F від A.
3. Помістіть F у власний модуль C і дозвольте їм використовувати і A, і B.

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

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

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

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

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

Чому так вони роблять. Але вони зменшують зв’язок між лініями. Що ви отримуєте, це сила змінити муфту. З'єднання буває у багатьох формах. Витяг коду збільшує непрямість і абстракцію. Збільшення може бути добрим чи поганим. Річ номер один, яка вирішує, яку ви отримаєте, це ім’я, яке ви використовуєте для цього. Якщо дивлячись на ім’я, мене дивує, коли я заглядаю всередину, то ти нікому не робив жодної прихильності.

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

З'єднання завжди буде, якщо ваша система не буде настільки ізольованою, що ніхто ніколи не дізнається, чи працює вона. Отже, з'єднання рефакторингу - це гра вибору вашої отрути. Слідом за DRY можна окупитися, зводячи до мінімуму з'єднання, створене шляхом висловлення одного і того ж дизайнерського рішення в багатьох місцях, поки це дуже важко змінити. Але DRY може унеможливити розуміння вашого коду. Найкращий спосіб врятувати цю ситуацію - знайти дійсно гарне ім’я. Якщо ви не можете придумати доброго імені, я сподіваюся, що ви вміли уникати безглуздих імен

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

Відповісти на заголовок - так, можна, але будьте готові до наслідків відправлення.

• Визначте інтерфейс F _A в A, що забезпечує функціональність F
• Визначте інтерфейс F _B у B
• Поставте F в С
• Створіть модуль D для управління всіма залежностями (це залежить від A, B і C)
• Адаптувати F до F _A і F _B в D
• Нанесіть (пропустіть) обгортки на А і В

Таким чином, єдиним типом залежностей, які ви мали б, є D залежно від кожного іншого модуля.

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

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

Чи Aвже залежить від цього Bчи навпаки? - в такому випадку ми можемо мати очевидний вибір будинку F.

Чи ділитесь Aі Bвже поділитесь якимись загальними залежностями, які могли б бути хорошим домом F?

Наскільки великий / складний F? Від чого ще Fзалежить?

Чи використовуються модулі Aта Bвикористовуються в одному проекті?

Буде чи Aі в Bкінцевому підсумку обміну деякі загальні в будь-якому випадку залежність?

Яка мова / модульна система використовується: Наскільки болісний новий модуль, болі програміста, ефективність роботи? Наприклад, якщо ви пишете на C / C ++ із системою модулів COM, що викликає біль у вихідному коді, вимагає альтернативного інструментального інструменту, має наслідки налагодження та має значення для продуктивності (для викликів між модулями), я можу зробіть якусь серйозну паузу.

З іншого боку, якщо ви говорите про Java або C # DLL, які досить легко поєднуються в одному середовищі виконання, це вже інша справа.

Функція - це абстракція і підтримує DRY.

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

Отже, я б заперечував, щоб створити кращу абстракцію Aі Bвід неї залежати, ніж просто перенести одну єдину функцію в новий модуль C. 

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

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

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

Запитайте себе, чому модулі A і B є окремими, якщо вони обидва залежать від однієї і тієї ж функції F? Звичайно, у вас виникнуть проблеми з управлінням залежностями / абстракцією / зчепленням / його-ім'ям, якщо ви дотримуєтесь поганого дизайну.

Правильне моделювання додатків проводиться відповідно до поведінки. Таким чином, фрагменти A і B, які залежать від F, потрібно витягти у власний, незалежний модуль. Якщо це неможливо, то A і B потрібно поєднувати. В будь-якому випадку A і B більше не корисні системі і повинні припинити своє існування.

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

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

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

Я маю іншу думку, принаймні щодо третього варіанту:

З вашого опису:

• А потребує F
• Б потребує F
• Ні А, ні В не потрібні один одному.

Введення F в модуль C не збільшує зв'язок, оскільки і A, і B вже потребують функції C.