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

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

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

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

СУХО (не се повтаряй)

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

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

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

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

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

Ако пишете на Java тогава присвоява частни на методи и променливи по подразбиране.

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

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

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

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

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

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

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

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

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

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

Горното е пример за код, при който AppManager зависи от EventLogWriter, който от своя страна е тясно свързан с AppManager. Ако имате нужда от различен начин за показване на известието, било то натискане, SMS или имейл, трябва да промените класа AppManager.

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

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

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

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

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

Дори "Ефективната Java" Джошуа Блок съветва да се предпочита композицията пред наследяването.

Принцип на заместване на Барбара Лисков (LSP)

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

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

Ето част от кода, който противоречи на LSP.

Методът area(Rectangle r) изчислява площта на правоъгълник. Програмата ще се срине след изпълнение на Square, тъй като Square не е правоъгълник тук. Съгласно принципа на LSP, функциите, които използват препратки към базови класове, трябва да могат да използват обекти на производни класове без допълнителни инструкции.

Този принцип, който е специфична дефиниция на подтип, беше предложен от Барбара Лисков в доклад на конференция от 1987 г., наречен "Абстракция на данни и йерархия" - оттук и името му.

Принцип на разделяне на интерфейса (ISP)

Още един СОЛИДЕН принцип. Според него интерфейс, който не се използва, не трябва да се прилага. Следването на този принцип помага на системата да остане гъвкава и преработваема, когато прави промени в логиката на работа.

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

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

Предимството на принципа на ISP в Java е, че всички методи трябва първо да бъдат имплементирани и едва след това да могат да се използват от класове. Следователно принципът позволява да се намали броят на методите.

Програмиране за интерфейс, а не за имплементация

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

Трябва да използвате тип интерфейс за променливи, връщани типове или типа на аргумент на метод. Пример е използването на SuperClass вместо SubClass.

Тоест:

Списък с номера= getNumbers();

Но не:

ArrayList numbers = getNumbers();

Ето практическа реализация на казаното по-горе.

Принцип на делегиране

Често срещан пример са методите equals() и hashCode() в Java. Когато два обекта трябва да бъдат сравнени, това действие се делегира на съответния клас вместо на клиентския клас.

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

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

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

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

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