У розробці програмного забезпечення, Об'єктно-орієнтований дизайн відіграє вирішальну роль, коли справа доходить до написання гнучкого, масштабованого, підтримуваного та багаторазового коду. Є так багато переваг використання OOD, але кожен розробник також повинен знати принцип SOLID для гарного об’єктно-орієнтованого дизайну в програмуванні. Принцип SOLID був представлений Робертом С. Мартіном, також відомим як дядько Боб, і це стандарт кодування в програмуванні. Цей принцип є абревіатурою п’яти принципів, наведених нижче:
- Принцип єдиної відповідальності (SRP)
- Відкритий/закритий принцип
- Принцип заміни Ліскова (LSP)
- Принцип сегрегації інтерфейсу (ISP)
- Принцип інверсії залежностей (DIP)
Принцип SOLID допомагає зменшити щільне зчеплення. Тісний зв’язок означає, що група класів сильно залежить один від одного, чого слід уникати у своєму коді.
- Протилежністю тісного зв’язку є слабкий зв’язок, і ваш код вважається хорошим кодом, якщо він має слабко пов’язані класи.
- Слабозв’язані класи мінімізують зміни у вашому коді, допомагають зробити код більш зручним для повторного використання, зручним для обслуговування, гнучким і стабільним. Тепер давайте обговоримо один за одним ці принципи...
1. Принцип єдиної відповідальності
Цей принцип стверджує, що Клас повинен мати лише одну причину для зміни це означає, що кожен клас має мати одну відповідальність, одну роботу чи єдину мету. Іншими словами, клас повинен мати лише одну роботу або мету в програмній системі.
вирівнювання тексту css
Давайте зрозуміємо принцип єдиної відповідальності на прикладі:
Уявіть пекаря, який відповідає за випікання хліба. Роль пекаря полягає в тому, щоб зосередитися на завданні випікання хліба, гарантуючи, що хліб має високу якість, правильно випечений і відповідає стандартам пекарні.
- Однак, якщо пекар також відповідає за управління запасами, замовлення витратних матеріалів, обслуговування клієнтів і прибирання пекарні, це порушить SRP.
- Кожне з цих завдань є окремою відповідальністю, і їх поєднання може поставити під загрозу зосередженість пекаря та ефективність випікання хліба.
- Щоб дотримуватися SRP, пекарня може призначати різні ролі різним особам або командам. Наприклад, може бути окрема особа або команда, відповідальна за управління запасами, інша – за замовлення витратних матеріалів, інша – за обслуговування клієнтів, а інша – за прибирання пекарні.
2. Принцип відкритості/закритості
Цей принцип стверджує, що Програмні сутності (класи, модулі, функції тощо) мають бути відкритими для розширення, але закритими для модифікації це означає, що ви повинні мати можливість розширити поведінку класу, не змінюючи його.
рядок до jsonobject
Розберемо принцип відкритості/закритості на прикладі:
Уявіть, що у вас є клас під назвою
PaymentProcessor>яка обробляє платежі для інтернет-магазину. Спочатку,PaymentProcessor>клас підтримує лише обробку платежів за допомогою кредитних карток. Однак ви хочете розширити його функціональність, щоб також підтримувати обробку платежів за допомогою PayPal.
Замість модифікації існуючогоPaymentProcessor>щоб додати підтримку PayPal, ви можете створити новий клас під назвоюPayPalPaymentProcessor>що розширюєPaymentProcessor>клас. Таким чином,PaymentProcessor>клас залишається закритим для модифікації, але відкритим для розширення, дотримуючись принципу відкритого-закритого
3. Принцип підстановки Ліскова
Принцип був введений Барбарою Лісковою в 1987 році і відповідно до цього принципу Похідні або дочірні класи повинні замінювати свої базові або батьківські класи . Цей принцип гарантує, що будь-який клас, який є нащадком батьківського класу, можна використовувати замість свого батька без будь-якої неочікуваної поведінки.
Розберемо принцип підстановки Ліскова на прикладі:
Одним із класичних прикладів цього принципу є прямокутник із чотирма сторонами. Висота прямокутника може мати будь-яке значення, а ширина – будь-яке значення. Квадрат - це прямокутник однакової ширини і висоти. Тож ми можемо сказати, що ми можемо розширити властивості класу прямокутника до класу квадрата.
Щоб зробити це, вам потрібно поміняти дочірній (квадратний) клас батьківським (прямокутний) клас, щоб відповідати визначенню квадрата з чотирма рівними сторонами, але похідний клас не впливає на поведінку батьківського класу, тому, якщо ви зробите що це порушить принцип заміни Ліскова.
4. Принцип поділу інтерфейсу
Цей принцип є першим принципом, який застосовується до інтерфейсів замість класів у SOLID, і він схожий на принцип єдиної відповідальності. У ньому зазначено, що не змушуйте жодного клієнта впроваджувати інтерфейс, який для нього не має відношення . Тут ваша головна мета — зосередитися на уникненні жирного інтерфейсу та надати перевагу багатьом невеликим клієнтським інтерфейсам. Вам слід віддавати перевагу багатьом клієнтським інтерфейсам, а не одному загальному інтерфейсу, і кожен інтерфейс має мати конкретну відповідальність.
пов'язаний список у java
Давайте зрозуміємо принцип сегрегації інтерфейсу на прикладі:
Припустимо, якщо ви заходите в ресторан і ви чистий вегетаріанець. Офіціант у цьому ресторані дав вам картку меню, яке включає вегетаріанські та невегетаріанські страви, напої та солодощі.
- У цьому випадку, як клієнт, ви повинні мати картку меню, яка містить лише вегетаріанські продукти, а не все, що ви не їсте у своїй їжі. Тут меню має бути різним для різних типів клієнтів.
- Загальну або загальну картку меню для всіх можна розділити на кілька карток замість однієї. Використання цього принципу допомагає зменшити побічні ефекти та частоту необхідних змін.
5. Принцип інверсії залежностей
Принцип інверсії залежностей (DIP) — це принцип об’єктно-орієнтованого проектування, який стверджує, що Модулі високого рівня не повинні залежати від модулів низького рівня. Обидва мають залежати від абстракцій . Крім того, абстракції не повинні залежати від деталей. Деталі повинні залежати від абстракцій.
- Простіше кажучи, DIP передбачає, що класи повинні спиратися на абстракції (наприклад, інтерфейси або абстрактні класи), а не на конкретні реалізації.
- Це дозволяє створити більш гнучкий і роз’єднаний код, полегшуючи зміну реалізацій, не впливаючи на інші частини кодової бази.
Давайте зрозуміємо принцип інверсії залежностей на прикладі:
У групі розробників програмного забезпечення розробники залежать від абстрактної системи контролю версій (наприклад, Git), щоб керувати та відстежувати зміни в кодовій базі. Вони не залежать від конкретних деталей внутрішньої роботи Git.
як відкрити файл за допомогою java
Це дозволяє розробникам зосередитися на написанні коду без необхідності розуміти тонкощі впровадження контролю версій.