Питання ставить помилкову дилему. Належне застосування принципу ЯГНІ не є якоюсь непов'язаною річчю. Це один з аспектів хорошого дизайну. Кожен із принципів SOLID - це також аспекти хорошого дизайну. Ви не завжди можете повністю застосовувати кожен принцип у будь-якій дисципліні. Проблеми в реальному світі накладають багато сил на ваш код, а деякі з них підштовхують до протилежних напрямків. Принципи дизайну повинні враховувати все це, але жодна жменька принципів не може відповідати всім ситуаціям.
Тепер давайте розглянемо кожен принцип з розумінням того, що, хоча вони іноді можуть тягнутись у різних напрямках, вони аж ніяк не суттєво конфліктують.
YAGNI був задуманий, щоб допомогти розробникам уникнути певного виду переробки: того, що випливає з побудови неправильної речі. Це робиться, керуючи нами, щоб уникнути занадто рано прийняття помилкових рішень на основі припущень чи прогнозів щодо того, що, на нашу думку, зміниться чи буде потрібно в майбутньому. Колективний досвід говорить нам, що коли ми робимо це, ми зазвичай помиляємось. Наприклад, YAGNI сказав би вам не створювати інтерфейс з метою повторного використання , якщо ви зараз не знаєте, що вам потрібно кілька реалізаторів. Так само YAGNI сказав, що не створюйте "ScreenManager" для управління єдиною формою в додатку, якщо ви зараз не знаєте, що у вас буде більше одного екрана.
Всупереч тому, що багато хто думає, SOLID не в тому, щоб використовувати їх повторно, простори чи навіть абстракції. SOLID призначений для того, щоб допомогти вам написати код, готовий до змін , нічого не кажучи про те, що може бути конкретною зміною. П’ять принципів SOLID створюють стратегію побудови коду, який є гнучким, не надто загальним і простим, не будучи наївним. Правильне застосування коду SOLID створює невеликі, зосереджені класи з чітко визначеними ролями та межами. Практичний результат полягає в тому, що для будь-якої необхідної зміни вимог необхідно торкнутися мінімальної кількості занять. І так само для будь-якої зміни коду існує мінімізована кількість "пульсацій" до інших класів.
Розглянувши приклад, який у вас є, давайте подивимось, що можуть сказати YAGNI та SOLID. Ви розглядаєте загальний інтерфейс сховища через те, що всі сховища зовні виглядають однаково. Але значення загального, загального інтерфейсу - це можливість використовувати будь-який з реалізаторів, не потребуючи того, щоб знати, який саме він є. Якщо у вашому додатку немає десь, де це було б необхідно чи корисно, YAGNI каже, що не робіть цього.
Існує 5 принципів СОЛІД, які слід переглянути. S - єдина відповідальність. Це нічого не говорить про інтерфейс, але це може сказати щось про ваші конкретні класи. Можна стверджувати, що обробка самим доступом до даних може бути відповідальною за один або декілька інших класів, тоді як відповідальність репозиторіїв полягає в перекладі з неявного контексту (клієнтський сховище неявно для суб'єктів Замовника) в явні виклики до узагальнений API доступу до даних із зазначенням типу юридичної особи Замовника.
O є відкритим-закритим. Це здебільшого стосується спадкування. Це застосовуватиметься, якщо ви намагалися отримати свої сховища із загальної бази, що реалізує загальну функціональність, або якщо ви очікували подальшого отримання з різних сховищ. Але ти це не так, це не так.
L - Заміна Ліскова. Це застосовується, якщо ви мали намір використовувати сховища через загальний інтерфейс сховища. Це встановлює обмеження на інтерфейс та реалізацію, щоб забезпечити узгодженість і уникнути спеціального поводження з різними імпелементами. Причиною цього є те, що така спеціальна обробка підриває мету інтерфейсу. Цей принцип може бути корисним, оскільки він може застерегти вас від використання загального інтерфейсу сховища. Це збігається з настановами YAGNI.
Я - інтерфейсна сегрегація. Це може застосовуватися, якщо ви почнете додавати різні операції із запитами у свої сховища. Сегрегація інтерфейсу застосовується там, де ви можете розділити членів класу на дві підмножини, де один буде використовуватися певними споживачами, а другий іншими, але жоден споживач, ймовірно, не використовує обидва підмножини. Настанова полягає у створенні двох окремих інтерфейсів, а не одного загального. У вашому випадку малоймовірно, що для отримання та збереження окремих екземплярів буде використовуватися той самий код, що і загальний запит, тому може бути корисно розділити їх на два інтерфейси.
D - ін'єкційна залежність. Тут ми повертаємось до тієї ж точки, що і S. Якщо ви розділили споживання API доступу до даних на окремий об'єкт, цей принцип говорить про те, що замість того, щоб просто створювати екземпляр цього об’єкта, вам слід передати його під час створення сховище. Це полегшує контроль за терміном експлуатації компонента доступу до даних, відкриваючи можливість обміну посиланнями на нього між вашими сховищами, не потребуючи проходження маршруту перетворення його на одиночний.
Важливо зазначити, що більшість принципів SOLID не обов'язково застосовуються на цьому конкретному етапі розробки вашої програми. Наприклад, від того, чи слід вам порушувати доступ до даних, залежить від того, наскільки це складно і чи ви хочете перевірити логіку вашого сховища, не потрапляючи в базу даних. Це здається, що це малоймовірно (на жаль, на мій погляд), тому, мабуть, це не потрібно.
Отже, після цього розгляду, ми виявляємо, що YAGNI і SOLID насправді надають один загальний твердий, негайно відповідний поради: Напевно, не потрібно створювати загальний інтерфейс сховища.
Вся ця ретельна думка надзвичайно корисна як навчальна вправа. Коли ви навчаєтесь, це забирає багато часу, але з часом ви розвиваєте інтуїцію і стає дуже швидким. Ви будете знати, що робити правильно, але не потрібно думати всі ці слова, якщо хтось не попросить вас пояснити чому.
(кого цікавить, це називається