Чи хотілося б вам знати чотири простих правила, виконання яких підвищує якість проєктування? Чотири правила, що допомагають скласти уявлення про найважливіші особливості структури та архітектури коду, спрощують застосування таких принципів, як SRP (принцип єдиної відповідальності) і DIP (принцип звернення залежностей)? Чотири правила, що сприяють гарному дизайну? Дехто вважає, що чотири правила простої архітектури Кента Бека [Beck, 1999] надають значну допомогу в проєктуванні програмних продуктів.

Згідно з Кентом, архітектура може вважатися «простою», якщо вона: 

1.     забезпечує проходження всіх тестів; 
2.     не містить дублювального коду; 
3.     висловлює наміри програміста; 
4.     використовує мінімальну кількість класів і методів. 

Правила наведені в порядку їх важливості.

Правило № 1: виконання всіх тестів

Насамперед система повинна робити те, що задумано проєктувальником. Система може бути чудово спланована «на папері», але якщо не існує простого способу переконатися в тому, що вона справді виконує свої завдання, то результат буде сумнівний.

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

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

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

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

Правила № 2–4: перероблення коду

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

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

Відсутність дублювання

Дублювання — головний ворог добре спроєктованої системи. Його наслідки — зайва робота, зайвий ризик і надлишкова складність. Дублювання проявляється у багатьох формах. Зазвичай точний збіг рядків коду свідчить про дублювання. Схожі рядки часто вдається «зачесати» так, щоб схожість стала ще більш очевидною; це спростить рефакторинг. Крім того, дублювання може існувати і в інших формах — таких, як дублювання реалізації. Наприклад, клас колекції може містити такі методи:

int size()  {} 

boolean isEmpty()  {}

Методи можуть мати різні реалізації. Припустімо, метод isEmpty може використовувати логічний прапор, а size — лічильник елементів. Однак ми можемо усунути дублювання, пов’язавши isEmpty з визначенням size: 

boolean isEmpty() {

       return 0 == size(); 

} 

Щоб створити чисту систему, необхідно свідомо прагнути усунення дублікатів, нехай навіть лише в декількох рядках коду. Для прикладу розгляньмо такий код:

Під час виокремлення спільності конструкцій на цьому мікроскопічному рівні починають проявлятися порушення принципу SRP. Так, щойно сформований метод можна перемістити в інший клас. Це розширює видимість методу. Інший член команди може знайти можливість подальшого абстрагування нового методу та його використання в  іншому контексті. Тож, принцип «повторного використання навіть у малому» може привести до значного скорочення складності системи.

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