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

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

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

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

DRY (Don’t Repeat Yourself)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По-горе е приведен пример за код, в който AppManager зависим от EventLogWriter, който от своя страна е тясно свързан с AppManager. Ако е необходим друг начин за показване на уведомление, било то push, SMS или email, трябва да промените класа 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 препоръчва:

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

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