10 принципів об'єктно-орієнтованого програмування, про які має знати кожен розробник

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

Нагадуємо: для всіх читачів "Хабра" - знижка 10 000 рублів при записі на будь-який курс Skillbox за промокодом "Хабр".

Skillbox рекомендує: Освітній онлайн-курс «Java-розробник».

СУХИ (не повторюйся)

Досить простий принцип, суть якого зрозуміла з назви: «Не повторюйся». Для програміста це означає необхідність уникнення дублюючого коду, а також можливість використовувати в роботі абстракцію.

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

Це потрібно для того, щоб спростити код і зробити його простіше, що є основним завданням ООП. Зловживати об'єднанням теж не варто, оскільки той самий код не пройде перевірку як з OrderId, так і з SSN.

Інкапсуляція змін

Програмні продукти більшості компаній постійно розвиваються. Значить, код потрібно вносити зміни, його потрібно підтримувати. Спростити життя можна за допомогою інкапсуляції. Це дозволить більш ефективно тестувати та підтримувати наявну базу коду. Ось один із прикладів.

Якщо ви пишете на Java, то за умовчанням надавайте private методам і змінним.

Принцип відкритості/закритості

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

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

Ось приклад коду, що порушує цей принцип.

Якщо в ньому потрібно щось змінити, на це піде багато часу, оскільки міняти доведеться всі ділянки коду, які мають зв'язок з потрібним фрагментом.

До речі, відкритість-закритість – один із принципів SOLID.

Принцип єдиної відповідальності (SRP)

Ще один принцип із набору SOLID. Він говорить, що «є лише одна причина, що призводить до зміни класу». Клас вирішує лише одне завдання. Він може мати кілька методів, але кожен із них використовується лише для вирішення спільного завдання. Усі методи та властивості повинні служити лише цьому.

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

Принцип інверсії залежностей (DIP)

Вище наведено приклад коду, де AppManager залежить від EventLogWriter, який, своєю чергою, тісно пов'язані з AppManager. Якщо потрібен інший спосіб показати повідомлення, будь то пуш, SMS або email, потрібно змінити клас AppManager.

Проблему можна вирішити за допомогою DIP. Так, замість AppManager ми запитуємо EventLogWriter, який буде введено за допомогою фреймворку.

DIP дозволяє без проблем замінювати окремі модулі іншими, змінюючи модуль залежності. Це дозволяє змінювати один модуль, не впливаючи на інші.

Композиція замість успадкування

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

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

Навіть "Effective Java" Джошуа Блох (Joshua Bloch) радить віддавати перевагу композиції, а не успадкування.

Принцип підстановки Барбари Лисків (LSP)

Ще один принцип із інструментарію SOLID. Він говорить, що підтипи мають бути замінними для супертипу. Тобто методи та функції, які працюють із суперкласом, повинні мати можливість без проблем працювати і з його підкласами.

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

Ось ділянка коду, що суперечить LSP.

Метод area (Rectangle r) прораховує площу Rectangle. Програма впаде після виконання Square, оскільки Square не є Rectangle. Відповідно до принципу LSP, функції, які використовують посилання на базові класи, повинні мати можливість використовувати об'єкти похідних класів без додаткових інструкцій.

Цей принцип, який є специфічним визначенням підтипу, було запропоновано Барбарою Лисков у 1987 році на конференції в основному доповіді під назвою «Абстракція даних та ієрархія» — звідси і його назва.

Принцип поділу інтерфейсу (ISP)

Ще один принцип SOLID. Відповідно до нього інтерфейс, який не використовується, не повинен бути реалізований. Дотримання цього принципу допомагає системі залишатися гнучкою та придатною для рефакторингу при внесенні змін до логіки роботи.

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

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

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

Програмування для інтерфейсу, а не реалізації

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

Слід використовувати тип інтерфейсу для змінних, повертаних типів або типу аргументу методу. Приклад – використання SuperClass, а не SubClass.

Тобто:

List numbers = getNumbers ();

А не:

ArrayList numbers = getNumbers();

Ось практична реалізація того, про що йдеться вище.

Принцип делегування

Найпоширеніший приклад - методи equals() і hashCode() в Java. Коли потрібно порівняти два об'єкти, ця дія делегується відповідному класу замість клієнтського.

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

Всі ці принципи дозволяють писати більш гнучкий, красивий і надійний код із високою зв'язністю та низьким зачепленням. Звичайно, теорія — це добре, але щоб розробник справді почав використовувати отримані знання, потрібна практика. p align="justify"> Наступним кроком після освоєння принципів ОВП може стати вивчення шаблонів проектування для вирішення загальних проблем розробки ПЗ.

Skillbox рекомендує:

• Практичний курс «Мобільний розробник PRO».
• Прикладний онлайн-курс "Аналітик даних на Python".
• Дворічний практичний курс "Я - Веб-розробник PRO".

Джерело: habr.com