Ілюзорне копіювання коду

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

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

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

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

Проблеми:

• відмінності настільки хвилинні, що код у всіх видах виглядає майже однаково ,
• Є так багато розбіжностей, що, дивлячись на деталі, кодувати не дуже схоже

Як мені впоратися з цією ситуацією?
Чи хороше рішення мати логіка ядра, що складається повністю з зворотних дзвінків?
Або я повинен скопіювати код і скинути складність коду на основі зворотного дзвінка?

Зрештою, вам слід прийняти рішення про те, чи слід поєднувати аналогічний код для усунення дублювання.

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

Як все в житті, ви повинні враховувати вигоди порівняно з витратами. Скільки дублюється код буде видалено? Скільки разів код повторюється? Скільки зусиль буде докладено, щоб написати більш загальний дизайн? Наскільки ви, ймовірно, розробляєте код у майбутньому? І так далі.

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

Недостатня увага до дизайну - це суттєвий камінь, але також остерігайтеся надмірного дизайну.

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

Частина знань може бути фактом ("максимально дозволене відхилення від запланованого значення становить 0,1%") або це може бути деяким аспектом вашого процесу ("ця черга ніколи не містить більше трьох елементів"). Це фактично будь-який єдиний фрагмент інформації, закодований у вихідному коді.

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

Чи планували ви використовувати стратегію ? У вас був би один клас View, який містить загальний код і підпрограми, викликані кількома представленнями. Діти класу Перегляд міститимуть код, специфічний для цих примірників. Всі вони використовуватимуть загальний інтерфейс, створений для перегляду, і, таким чином, відмінності будуть інкапсульовані та узгоджені.

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

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

Як зазначалося @ dan1111, він може прийти до виклику судового рішення. З часом ви можете виявити, працює він чи ні.

Одне питання може полягати в тому, що ви надаєте інтерфейс (теоретичний інтерфейс, а не мовна функція) лише для одного рівня функціональності:

A(a,b,c) //a,b,c are your callbacks or other dependencies

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

//high level
A(a,b,c)
//lower
A myA(a,b)
B(myA,c)
//even lower
A myA(a)
B myB(myA,b)
C myC(myB,c)
//all the way down to you just having to write the code yourself

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

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

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

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

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

Використовуйте функціонал найнижчого рівня, коли має статися якесь дивацтво.

Його також не дуже чорно-білі. Можливо, ваш великий клас високого рівня МОЖЕ розумно охопити всі можливі випадки використання. Можливо, випадки використання настільки різні, що не вистачає нічого, окрім примітивної функціональності найнижчого рівня. Ви повинні знайти баланс.

Вже є інші корисні відповіді. Я додам свою.

Дублювання погано, тому що

1. це захаращує код
2. це захаращує наше схвалення коду, але найголовніше
3. тому що якщо ви щось тут поміняєте і вам теж доведеться щось змінити там , ви можете забути / ввести помилки / .... і важко ніколи не забути.

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

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