Лабораторно упражнение 1

Принципите SOLID

Принципите SOLID са въведени от Робърт Ч. Мартин в неговия труд от 2000 г. "Принципи на дизайна и модели на дизайна". Това понятие по-късно са надградено от Майкъл Пера, който въвежда акронима SOLID. През последните 20 години тези пет принципа революционизираха света на обектно-ориентираното програмиране, променяйки начина, по който се пише софтуер.

Какво е SOLID и как ни помага да напишем по-добър код?

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

Нека да разгледаме следния пример:

Когато една сграда се строи с лоши тухли, архитектурата на сградата няма голямо значение. От друга страна ако не знаем как да редим тухлите бъркотията също може да е голяма.

Ако разгледаме примера в програмирането това е мястото къдто влизат принципите на SOLID. Принципите на SOLID ни казват как да подредим нашите функции и структури от данни в класове и как тези класове трябва да бъдат свързани помежду си.

Използването на Думата „клас” не означава, че тези принципи са приложими само към обектно-ориентираното програмиране. Класът е просто свързано групиране на функции и данни. Всяка софтуерна система има такива групи, независимо дали се наричат класове или не. Принципите на SOLID се прилагат за тези групи от функции и данни и дори до по ниско ниво като функция или структура от данни, които ще наричаме елементи/елементи на софтуера

Следните пет понятия съставляват SOLID принципите:

Инициал	Акроними	Концепция
S	SRP - Single Responsibility Principle	Принцип за единствена отговорност Това ще рече, че всеки елемент на софтуера има една работа и само една причина за промяна.
O	OCP - Open-Closed Principle	Принципът отворено-затворено Същността е, че за да бъдат лесни за промяна всички елемент на софтуера, трябва да бъдат проектирани така, че да позволяват поведението на елементите да бъде променено чрез добавяне на нов код, а не промяна на съществуващ код.
L	LSP - Liskov Substitution Principle	Принцип на заместване на Лисков Всеки наследник (подтип) трябва лесно да заменя всичките си базови типове.
I	ISP - Interface Segregation Principle	Принцип за разделяне на интерфейсите Много на брой малки интерфейси е по-добре от един голям общ интерфейс. Това означава, че не е нужно да зависим от неща които не ползваме
D	DIP - Dependency Inversion Principle	Принцип на обръщане на зависимостите Всички класове от високо ниво трябва да дефинират абстракции и нито един не трябва да зависи от конкретен клас. Класовете от ниско ниво, може да зависят от абстракциите.