10 принципа на обектно-ориентираното програмиране, които всеки разработчик трябва да знае

Срещам доста често разработчици, които не са чували за принципите SOLID (ние подробно сме говорили за тях тук. — Прев.) или за обектно-ориентираното програмиране (ООП), или са чували, но не ги използват на практика. В тази статия се описват предимствата на принципите на ООП, които помагат на разработчиците в ежедневната им работа. Някои от тях са добре известни, други – не толкова, така че статията ще бъде полезна за новици и за опитни програмисти.

Напомняме: за всички читатели «Хабра» — отстъпка от 10 000 рубли при записване на който и да е курс Skillbox с промокод «Хабр».

Skillbox препоръчва: Образователен онлайн курс «Java-разработчик».

DRY (Don’t Repeat Yourself)

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

Ако в кода има два повтарящи се участъка, те трябва да се обединят в един метод. Ако многократно се използва зададено значение, то трябва да се преобразува в публична константа.

Това е необходимо, за да се опрости кодът и да се улесни поддръжката му, което е основната задача на ООП. Не трябва да се злоупотребява с обединенията, тъй като един и същ код няма да премине проверка и с OrderId, и с SSN.

Инкапсулация на промените

Продуктите на повечето компании постоянно се развиват. Следователно, в кода трябва да се правят промени, необходимо е да се поддържа. Можете да улесните живота си чрез инкапсулация. Това ще позволи по-ефективно тестване и поддръжка на съществуващата база код. Ето един от примерите.

Ако пишете на Java, то по подразбиране задавайте private на методите и променливите.

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

Този принцип може лесно да бъде запомнен, прочитайки следното твърдение: «Програмните единици (класове, модули, функции и т.н.) трябва да са отворени за разширение, но затворени за изменения». На практика това означава, че те могат да позволят промяна в поведението си без изменение на изходния код.

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

Ето пример за код, който нарушава този принцип.

Ако в него трябва нещо да бъде променено, това ще отнеме много време, тъй като ще трябва да се променят всички участъци от кода, които имат връзка с необходимия фрагмент.

Между другото, откритостта и затвореността е един от принципите на SOLID.

Принцип на единствената отговорност (SRP)

Още един принцип от набора SOLID. Той гласи, че "съществува само една причина, която води до промяна на класа". Класът решава само една задача. Той може да има няколко метода, но всеки от тях се използва само за решаване на обща задача. Всички методи и свойства трябва да служат само на това.

Ценността на този принцип е, че той отслабва връзката между отделния компонент на софтуера и кода. Ако добавите повече от една функционалност в клас, това въвежда връзка между две функции. Така, ако промените едната от тях, е много вероятно да повредите втората, свързана с първата. А това означава увеличаване на цикли за тестване, за да се открият всички проблеми предварително.

Принцип на инверсия на зависимостите (DIP)

По-горе е даден пример за код, в който AppManager зависи от EventLogWriter, който, от своя страна, е тясно свързан с AppManager. Ако е необходим различен начин за показване на уведомление, било то пуш, SMS или имейл, ще трябва да промените класа AppManager.

Проблемът може да бъде решен с помощта на DIP. Вместо AppManager, ние заявяваме EventLogWriter, който ще бъде внедрен с помощта на фреймуърка.

DIP позволява безпроблемно заместване на отделни модули с други, променяйки модула на зависимостта. Това дава възможност да се променя един модул, без да се влияе на останалите.

Композиция вместо наследяване

Основните начини за повторно използване на код са два — наследяване и композиция, като всеки от тях има свои предимства и недостатъци. Обикновено предпочитание се дава на втория, тъй като той е по-гъвкав.

Композицията дава възможност за промяна на поведението на класа по време на изпълнение чрез задаване на неговите свойства. При реализацията на интерфейсите се използва полиморфизъм, който осигурява по-гъвкава реализация.

Дори „Effective Java” на Джошуа Блох съветва да се предпочита композицията, а не наследяването.

Принципът на заместване на Барбара Лисков (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. Когато е необходимо да се сравнят два обекта, това действие се делегира на съответния клас, а не на клиентския.

Предимството на принципа е отсъствието на дублиране на код и сравнително лесната промяна на поведението. Освен това той се прилага за делегиране на събития.

Всички тези принципи позволяват да пишете по-гъвкав, красив и надежден код с висока свързаност и ниско сцепление. Разбира се, теорията е хубава, но за да започне разработчикът наистина да използва придобитите знания, е необходима практика. Следващата стъпка след усвояването на принципите на ООП може да бъде изучаване на шаблони за проектиране за решаване на общи проблеми в разработката на софтуер.

Skillbox препоръчва:

• Практически курс «Мобилен разработчик ПРО».
• Прикладен онлайн курс „Аналитик на данни с Python“.
• Двугодишен практически курс „Аз съм уеб разработчик PRO“.

Източник: habr.com