Всяка професия си има основите, които после раждат общите теми за всички, които я практикуват. В много от по-старите поприща основите са доста по-размити, дори диаметрално противоположни и обречени на вечни спорове.
Не и в програмирането. Тук SOLID, 5-те основни правила, обобщени преди някакви си 20 години, определено днес са стандарт. Удобен въпрос, който да поставиш на начинаещ (и не само) програмист, явил се на интервю; удобна обосновка, за да критикуваш нечий код, докато му правиш задължителното код ревю.
А може би тези правила просто наистина са толкова добри, че събират в себе си всичко важно? Нека опитаме да ги разгледаме накратко, без особени претенции за превода на сложната терминология и за навлизане в дълбочина, по-скоро на основата на логиката, която се крие зад всяко от правилата.
Солидно начало
SOLID са петте основни принципа на обектно-ориентираното програмиране. На доста места ще срещнете информацията, че това е антонимът на функционалното програмиране, но истината е, че двете основни направления в начина, по който „даваме акъл“ на компютрите през последните години се развиват и допълват. Успешно работят заедно. Така, че наистина да можем да изстискаме най-доброто от компютърните програми, които днес се използват в огромната си част онлайн. При това използват компютърни езици, които си приличат много сериозно по основната си логика, базирана на езика С.
Да, всяка професия може да бъде събрана в няколко постулата. При това – съкращението от първите им букви да значи нещо. Обаче е трудно, дори почти невъзможно да избереш такива, които да станат общоприети, при това за професия, която е толкова динамична. Затова е направо впечатляващо, че днешното програмиране си има SOLID.
Съ…трудничене
В случая сполучва да намери точното решение през 2000 г. Робърт Мартин, обичащ да го представят като „Чичо Боб“. Но той само формулира основните принципи, чак 4 години по-късно един негов последовател се сеща за съкращението, което днес е прието за универсалното правило на програмистите.
И така, какво представляват тези 5 SOLID принципа, съвсем лаконично, при това дори без буквичка компютърен код? Целта ни е да разкажем за съвсем общата идея на всеки от тях, а примери на своя любим компютърен език всеки от вас може да намери колкото си иска онлайн…
Не случайно същият Чичо Боб е и сред авторите на „Манифеста Agile“, още една магическа думичка, която доста често чува всеки, изкушил се в наши дни да се насочи професионално към програмирането.
А общото между двете е целта. „Да се създава разбираем, четим и подлежащ на тестване код, по който много програмисти могат да работят едновременно, като си сътрудничат“.
Single-responsibility: Само това умея…
Официално първият принцип гласи: „Не бива да има повече от една причина един клас да се променя. Всеки клас трябва да има само една отговорност“.
И така, накратко ще резюмираме основната идея зад всеки от принципите. Които, разбира се, не са толкова лесни за разбиране и обясняване, иначе всеки щеше да се справя доста успешно на интервюто за работа като програмист.
Казано съвсем грубо, този принцип изисква да разделяме компютърния код на възможно най-малки единици, така че да постигнем такива, които наистина са опростени дотолкова, че да вършат точно една малка своя задача. А ако тя стане по-сложна, да я разделят на други едицини, които вече да поемат нейното изпълнение. И така, докато сме сигурни, че наистина всеки клас и всяка функция вършат точно само и едно нещо. И то е точно причината, поради която в някакъв момент се налага да бъдат променени.
В програмирането особено важно значение има начинът, по който кръщаваме функциите и променливите. Конкретно за това правило може да ни ориентира подходът за именуване – ако ни идва да опишем действието на дадена функция така, че тя прави „и още нещо“, значи определено не се спазва добрият стар първи принцип сред основите на SOLID.
Open-closed: Отваряме, затваряме
Официално гласи: „Софтуерните обекти трябва да бъдат отворени за допълване, но затворени за променяне“.
Не, това, както стана дума, е принцип, дошъл доста преди коронавируса, нищо, че толкова точно отразява в основната си формулировка всичко, което ни се случи пред последните две години. Отваряме, затваряме, после пак….
Отново с уговорката, че формулировката е много груба, основната идея тук е, че обектите, класовете, функциите, отделните градивни единици на кода трябва да бъдат създавани по такъв начин, че лесно да се допълват, например така че да покрият някакви случаи от нови тип. Но не и да се променят, защото по този начин рискуваме да създадем проблеми и за начина, по който са действали до момента.
Може би не сте се замисляли често, че програмистите се наричат и софтуерни инженери. Инженерното начало в създаването на компютърни програми е безспорен факт и това може да бъде проследено във всеки от SOLID принципите.
Liskov substitution: Смяна в редовното време
Официално гласи: „Всеки наследник (подтип) трябва лесно да заменя всичките си базови типове.“
Този принцип носи името на американската изследователка Барбара Лисков. Бидейки и автор на езици за програмиране, тя формулира принципа, който остава в абревиатурата с фамилното ѝ име.
Тук вече напредваме с абстракцията, нещо особено характерно за програмирането, затова не можем да се доближим дори до истинския смисъл на идеята, която наистина иска доста повече обяснения. И все пак, тук наистина основната точка е абстракцията. Важно е всеки от отделните малки обекти или класове, да може да използва основните закони, заложени в по-абстрактния клас, който наследява. И все пак, да може да ги допълва и развива така, че да отговарят конкретно на неговите нужди.
Interface segregation: Аз си знам
Официално гласи: „Много на брой малки интерфейси са по-добро решение от един голям общ интерфейс“.
Идеята тук е, че отделните типове обекти често наистина се различават помежду си. Затова е по-добре да извеждаме абстракцията на колкото е възможно по-високо ниво. В този смисъл, един определен интерфейс, рамката, която трябва да дава само базовите и наистина общи неща, не е логично да бъде прекалено конкретна, точно защото си остава преди всичко рамка.
Съответно, разликите могат и трябва да бъдат допълвани от малки, по-семпли и прецизни допълнителни интерфейси на следващото ниво. Това със сигурност е един от принципите, който става доста по-ясен, когато се напредне и с практиката.
Dependency inversion: Бягство от отговорност
Официално гласи: „Зависимост от абстракцията, не от конкретиката“.
Или „Всички класове трябва да зависят от абстракции и нито един не трябва да зависи от конкретен клас.“
И така, завършваме този фундаментален списък с едно правило, което звучи колкото дзен, толкова и абстрактно, а същевременно – говори за най-високата степен на абстракция, до която стигаме.
Още едно от определенията на този принцип гласи, че всеки наследяващ клас би трябвало да може да бъде заменен от този, когото наследява, без това да създаде проблеми.
И така, ето че завършихме бързата си обиколка през петте SOLID принципа. Заедно с KISS, DRY и YAGNI, за които вече сме ви разказвали, те са едновременно задължителни основи и доста абстрактни идеи, които всеки би трябвало да преоткрива сам, напредвайки в програмирането.
А ако и вас ви влече това занимание, чудесно място, където да започнете със своя първи проект, е безплатният хостинг, който ви предлагаме. Тук е идеалното място, за да започнете. Не се колебайте!
