У Java, Тверді принципи є об'єктно-орієнтованим підходом, який застосовується до проектування структури програмного забезпечення. Це концептуалізовано Роберт С. Мартін (також відомий як дядько Боб). Ці п’ять принципів змінили світ об’єктно-орієнтованого програмування, а також змінили спосіб написання програмного забезпечення. Це також гарантує, що програмне забезпечення є модульним, простим для розуміння, налагодження та рефакторингу. У цьому розділі ми обговоримо Принципи SOLID в Java з належним прикладом .

повна форма пвр

Слово SOLID є акронімом для:

• Принцип єдиної відповідальності (SRP)
• Відкритий-закритий принцип (OCP)
• Принцип заміни Ліскова (LSP)
• Принцип сегрегації інтерфейсу (ISP)
• Принцип інверсії залежностей (DIP)

Давайте детально пояснимо принципи один за іншим.

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

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

Припустимо, студент це клас, який має три методи, а саме printDetails(), calculatePercentage(), і addStudent(). Отже, клас Student має три обов’язки: друкувати інформацію про студентів, обчислювати відсотки та базу даних. Використовуючи принцип єдиної відповідальності, ми можемо розділити ці функції на три окремі класи для досягнення мети принципу.

Student.java

 public class Student { public void printDetails(); { //functionality of the method } pubic void calculatePercentage(); { //functionality of the method } public void addStudent(); { //functionality of the method } } 

Наведений вище фрагмент коду порушує принцип єдиної відповідальності. Для досягнення мети принципу ми повинні реалізувати окремий клас, який виконує лише одну функціональність.

Student.java

 public class Student { public void addStudent(); { //functionality of the method } } 

PrintStudentDetails.java

 public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } 

Percentage.java

 public class Percentage { public void calculatePercentage(); { //functionality of the method } } 

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

Принцип «відкрито-закрито».

Додаток або модуль містять методи, функції, змінні тощо. Принцип «відкрито-закрито» стверджує, що відповідно до нових вимог модуль має бути відкритим для розширення, але закритим для модифікації. Розширення дозволяє реалізувати нову функціональність модуля. Розберемо принцип на прикладі.

Припустимо, VehicleInfo є класом і має метод vehicleNumber() який повертає номер автомобіля.

numpy означає

VehicleInfo.java

 public class VehicleInfo { public double vehicleNumber(Vehicle vcl) { if (vcl instanceof Car) { return vcl.getNumber(); if (vcl instanceof Bike) { return vcl.getNumber(); } } 

Якщо ми хочемо додати ще один підклас під назвою Truck, ми просто додаємо ще один оператор if, який порушує принцип відкритого-закритого. Єдиний спосіб додати підклас і досягти мети принципу шляхом перевизначення vehicleNumber() метод, як ми показали нижче.

VehicleInfo.java

 public class VehicleInfo { public double vehicleNumber() { //functionality } } public class Car extends VehicleInfo { public double vehicleNumber() { return this.getValue(); } public class Car extends Truck { public double vehicleNumber() { return this.getValue(); } 

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

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

Принцип заміни Ліскова (LSP) був введений Варвара Ліскова . Це стосується спадкування таким чином, що похідні класи повинні бути повністю замінними для своїх базових класів . Іншими словами, якщо клас A є підтипом класу B, тоді ми повинні мати можливість замінити B на A, не перериваючи поведінку програми.

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

Student.java

 public class Student { private double height; private double weight; public void setHeight(double h) { height = h; } public void setWeight(double w) { weight= w; } ... } public class StudentBMI extends Student { public void setHeight(double h) { super.setHeight(h); super.setWeight(w); } public void setWeight(double h) { super.setHeight(h); super.setWeight(w); } } 

Наведені вище класи порушують принцип заміни Ліскова, оскільки клас StudentBMI має додаткові обмеження, тобто зріст і вага, які повинні бути однаковими. Тому клас Student (базовий клас) не можна замінити класом Student BMI (похідним класом).

git pull origin master

Отже, заміна класу Student на клас StudentBMI може призвести до несподіваної поведінки.

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

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

Мета принципу відокремлення інтерфейсу подібна до принципу єдиної відповідальності. Розберемо принцип на прикладі.

Припустимо, ми створили інтерфейс під назвою Перетворення маючи три методи intToDouble(), intToChar(), і charToString() .

 public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } 

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

 public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } 

Тепер ми можемо використовувати лише той метод, який потрібен. Припустімо, ми хочемо перетворити ціле число на подвійне і символ на рядок, тоді ми будемо використовувати лише методи intToDouble() і charToString().

 public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } 

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

Принцип стверджує, що ми повинні використовувати абстракцію (абстрактні класи та інтерфейси) замість конкретних реалізацій. Модулі високого рівня не повинні залежати від модуля низького рівня, але обидва мають залежати від абстракції. Тому що абстракція не залежить від деталей, а деталь залежить від абстракції. Це роз’єднує програмне забезпечення. Розберемо принцип на прикладі.

 public class WindowsMachine { //functionality } 

Варто, якщо у нас немає клавіатури та миші для роботи на Windows. Щоб вирішити цю проблему, ми створюємо конструктор класу та додаємо екземпляри клавіатури та монітора. Після додавання екземплярів клас виглядає так:

 public class WindowsMachine { public final keyboard; public final monitor; public WindowsMachine() { monitor = new monitor(); //instance of monitor class keyboard = new keyboard(); //instance of keyboard class } } 

Тепер ми можемо працювати на машині Windows за допомогою клавіатури та миші. Але ми все ще стикаємося з проблемою. Тому що ми тісно поєднали три класи разом за допомогою нового ключового слова. Важко перевірити машину класу windows.

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

Keyboard.java

розбиття рядка c++

 public interface Keyboard { //functionality } 

WindowsMachine.java

 public class WindowsMachine { private final Keyboard keyboard; private final Monitor monitor; public WindowsMachine(Keyboard keyboard, Monitor monitor) { this.keyboard = keyboard; this.monitor = monitor; } } 

У наведеному вище коді ми використали ін’єкцію залежностей, щоб додати залежність клавіатури в клас WindowsMachine. Тому ми роз’єднали класи.

Чому ми повинні використовувати принципи SOLID?

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

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