Принципи об'єктно-орієнтованого дизайну (далі ООД) - ядро об'єктно-орієнтованого програмування на Java (далі - ООП), але я бачу більшість Java-програмістів, що працюють з патернами Singleton ("Одиночка", наприклад Singleton ), "Декоратор" ( Decorator ) або "Спостерігач" ( Observer ), які не приділяють належної уваги вивченню об'єктно-орієнтованого аналізу та дизайну. Звичайно, важливо вивчати основи ОВП : абстракція, інкапсуляція, поліморфізм і спадкування, але водночас не менш важливо знати принципи дизайну, щоб створювати добре структуровані та зрозумілі продукти. Постійно спостерігаю програмістів, розробників різного рівня, які або не чули про принципи ООД SOLID, або просто не знають про переваги, які той чи інший принцип дизайну дає, або як застосувати його в коді. У підсумку, завжди прагнете до зв'язності коду та гарного дизайну у вирішенні. Відмінні приклади вивчення Java і ООД — відкритий код Apache і Sun. Вони демонструють, як принципи ООД повинні використовуватися в написанні коду, програмах Java. Ілюстрація застосування патернів у JDK: Factory, патерн «фабрика» у класі BorderFactory , Що таке патерн дизайну Factory... , патерн Singleton, «одиначка», у класі Runtime RunTime , патерн Decorator, «декоратор», у різних java.io класах . До речі, якщо ви зацікавлені практикуватися в java-коді, прочитайте Effective Java, Joshua Bloch (наприклад,Effective Java у перекладі російською ), шедевр від автора Java API. Ще на тему ООД та патернів рекомендую Head First Design Pattern, а також Head First Object Oriented Analysis and Design. Ці книги допоможуть писати найкращий код, використовуючи переваги принципів ООД. Хоча найкращий спосіб засвоїти будь-які принципи — практикуватися і розуміти наслідки порушення цих самих принципів, тема цієї статті — запровадження принципів ООД для java-програмістів, які поки що їх не використовують або лише вивчають мову. Я вважаю, кожен із озвучених принципів ООД ( SOLID ) гідний окремої статті з докладним поясненням суті, і я надалі постараюсь (написати ці статті — прим. перекл.), але зараз приготуйтеся просто швидко пробігтися.DRY (Не повторюйтесь) Першим принципом позначимо «не повторюйтеся», що означає, не пишіть коду, що повторюється, використовуйте принцип абстракції, узагальнюючи прості речі в одному місці. Якщо у вас є один і той же блок коду більше, ніж у двох місцях, подумайте про окремий метод для нього. Якщо є константа багаторазового використання, створіть глобальну змінну з модифікаторами public final. Великою перевагою використання цього принципу є легкість подальшої технічної підтримки. Важливо також зловживати цим принципом, коли, наприклад, повторення коду існує задля самого коду, а реалізації функціональності. Наприклад, коли ви перевіряєте OrderID і SSN, це означає, що вони ідентичні чи стануть такими у майбутньому. Використовуючи однаковий код для двох різних функцій або елементів, ви пов'язуєте їх тісно, і коли OrderID змінить формат, код перевірки SSN перестане працювати. Майте на увазі такі зв'язки і не комбінуйте все поспіль, що використовує схожий код, але насправді не є пов'язаним.
Інкапсулюйте те, що змінюється Одна річ постійна у світі програмного забезпечення – зміна. Інкапсулюйте код, який у майбутньому змінюватиметься. Перевага принципу у легкості тестування та підтримки належним чином інкапсульованого коду. При написанні програм на java дотримуйтесь, за замовчуванням, правила створення змінних та методів з модифікатором доступу private, розширюючи доступ крок за кроком, від private до protected, але не public. Кілька принципів дизайну java використовують інкапсуляцію, патерн Factory — хороший приклад, де код створення об'єктів інкапсульований і досить гнучкий, щоб створювати нові об'єкти, але без впливу на існуючий код.
Відкрито-закритий принцип дизайну Класи, методи, функції мають бути відкриті для розширення (нової функціональності) та закриті для модифікації. Це відмінний принцип набору
SOLID , що відповідає букві «О», що запобігає зміні протестованого та працюючого коду. Ідеально, якщо ви додаєте нову функціональність тільки, коли ваш код повинен тестуватись, і в цьому мета цього принципу ООД.
Принцип унікальної відповідальності (SRP) SRP відповідає букві S в SOLID і означає, що не повинно існувати більше 1 причини для зміни класу, іншими словами, клас повинен мати унікальну функціональність. Якщо один клас java реалізує 2 набори функцій, їх зчеплення створює ситуацію, при якій зміна одного порушить наявне поєднання, що вимагатиме нового раунду тестування, щоб уникнути сюрпризів при використанні програм.
Впровадження залежностей (DI) або принцип інверсії управління (IOC) Не просіть залежності, фреймворк вам її забезпечить. Цей принцип добре реалізований у фреймворку Spring. Принадність принципу в тому, що будь-який клас із впровадженою залежністю (DI, частина фреймворку Spring), легко тестувати за допомогою об'єкта-муляжу і легко підтримувати, тому що код, що створює об'єкт, інкапсульований у фреймворку, і не поєднується з клієнтським кодом. Існує безліч способів впроваджувати залежності, наприклад, використовуючи інструментарій у байт-коді від фреймворків
аспектно-орієнтованого програмування типу AspectJ або використовуючи проксі, як у Spring. Перегляньте цей приклад використання принципу
DI & IOC , що представляє букву D в абревіатурі SOLID.
Віддайте перевагу структурі успадкування Завжди ставте на перше місце структуру, композицію, якщо це можливо. Хтось може сперечатися з цим твердженням, але я вважаю, що пріоритет композиції - набагато гнучкіший підхід, ніж реалізація через успадкування. Композиція дозволяє змінити поведінку класу під час виконання, задаючи властивості у поточному режимі. Використання інтерфейсів для створення класу, застосування поліморфізму, дає нам гнучкість у покращенні реалізації щоразу. Навіть у книзі Effective Java йдеться про перевагу композиції над спадкуванням.
Принцип підстановки Лісків (LSP) Відповідно до принципу
LSP, літера L у SOLID, функції, які використовують посилання на базові класи, повинні мати можливість використовувати об'єкти похідних класів, не знаючи про це. LSP тісно пов'язаний із принципом унікальної відповідальності та принципом поділу інтерфейсів. Якщо базового класу більше функціональності, ніж у похідного, таке співвідношення порушує принцип LSP. Щоб дотримуватися цього принципу, похідний клас чи підклас має розширювати функціональність, а чи не звужувати її.
Принцип поділу інтерфейсів (ISP) Даний принцип говорить, що клас не повинен впроваджувати інтерфейс
.) , якщо інтерфейс не використовується. В основному таке відбувається, коли інтерфейс багатофункціональний, а клас вимагає лише однієї функціональності. Розробка інтерфейсів - складна робота, реалізувавши інтерфейс, важко змінити його без зміни всієї реалізації. Інша перевага використання принципу ISP полягає в тому, що інтерфейс впроваджує методи до того, як будь-який клас може їх використовувати, тому унікальна функціональність вимагає впровадження меншої кількості методів.
Програмування для інтерфейсу, а не для реалізації «Завжди програмуйте для інтерфейсу, а не для реалізації.» Наслідування цього принципу призведе вас до гнучкого коду, який зможе працювати з будь-якою новою реалізацією інтерфейсу. Використовуйте
змінні інтерфейсного типу, методи з значенням, що повертається або методи з параметрами. Ті ж поради містяться в Effective Java та книгах з ООД.
Принцип делегування Не робіть все самостійно, доручіть роботу відповідному класу. Хрестоматійний приклад застосування принципу делегування – використання методів equals() та hashCode(). Для порівняння двох об'єктів ми доручаємо класу самостійно зробити цю роботу замість того, щоб залишати перевірку клієнтському класу. Перевага цього принципу у запобіганні подвійного коду та легкості у зміні поведінки. Всі викладені принципи об'єктно-орієнтованого дизайну допоможуть вам писати гнучкий та найкращий код, зв'язковий, але без зайвих зв'язок. Теорія – перший крок. Найважливіше розвивати здатність до аналізу, де застосовні ці принципи ООД. Слідкуйте, чи не порушуєте ви якийсь із принципів, наражаючи на небезпеку гнучкість коду. Разом з тим, ніщо не зовсім неможливо завжди вирішувати проблеми тільки застосуванням принципів ООД у програмуванні.
У підсумку, завжди прагнете до зв'язності коду та гарного дизайну у вирішенні. Відмінні приклади вивчення Java і ООД — відкритий код Apache і Sun. Вони демонструють, як принципи ООД повинні використовуватися в написанні коду, програмах Java. Ілюстрація застосування патернів у JDK: Factory, патерн «фабрика» у класі BorderFactory , Що таке патерн дизайну Factory... , патерн Singleton, «одиначка», у класі Runtime RunTime , патерн Decorator, «декоратор», у різних java.io класах . До речі, якщо ви зацікавлені практикуватися в java-коді, прочитайте Effective Java, Joshua Bloch (наприклад,Effective Java у перекладі російською ), шедевр від автора Java API. Ще на тему ООД та патернів рекомендую Head First Design Pattern, а також Head First Object Oriented Analysis and Design. Ці книги допоможуть писати найкращий код, використовуючи переваги принципів ООД. Хоча найкращий спосіб засвоїти будь-які принципи — практикуватися і розуміти наслідки порушення цих самих принципів, тема цієї статті — запровадження принципів ООД для java-програмістів, які поки що їх не використовують або лише вивчають мову. Я вважаю, кожен із озвучених принципів ООД ( SOLID ) гідний окремої статті з докладним поясненням суті, і я надалі постараюсь (написати ці статті — прим. перекл.), але зараз приготуйтеся просто швидко пробігтися.