Какво можете да направите, когато нарушавате принципа на OCP от SOLID?
Един от най-честите въпроси в интервютата за техническо инженерство е: какво е S.O.L.I.D и дали можете да предоставите няколко примера за всеки принцип.
Има много ресурси, които проповядват как трябва да работи SOLID. На практика обаче дяволът е в детайлите.
Принципът отворено-затворено
Какво е?
Обектите или обектите трябва да са отворени за разширение, но затворени за модификация.
Това означава, че даден обект трябва да може да се разширява, без да се променя самият обект.
Признак номер едно за нарушаване на OCP е използването на if-else или switch изрази. Като странична бележка, всяко разклоняване на if-else или switch трябва да повдигне малък въпросителен знак за възможна миризма на код.
Примери за ситуации, които можете да намерите във вашата кодова база:
Представете си, че бизнес изискванията се променят и трябва да добавите AnalyticsLogger, който ще записва в GoogleAnalytics или в FacebookAnalytics.
Вашият Logger клас е отворен за разширение, но в същото време ще бъде отворен и за модификация (тъй като всъщност трябва да добавите нов switch case), което нарушава OCP.
Да видим друг пример:
Избор между различни възможности за съхранение с логика на разклоняване if-else: първо и най-вече, миризмата на лош код е използването на низови литерали, които не са константи или енуми: толкова много лоши неща и грешки могат да произтекат от това, но това е друга история.
Да приемем, че Product Owner идва след един месец и иска възможността приложението да съхранява нещо в паметта вместо двата постоянни начина. Какво се случва тогава? Друг сценарий за else if случай и по-късно още един и т.н.
Други сценарии могат да бъдат, но не се ограничават до:
Можем ясно да видим модел, който се появява тук.
Сега естественият въпрос е как да го поправим? Как можем да го предотвратим?
Всички възможни сценарии за внедряване трябва да отговарят на някаква абстракция (интерфейс, протокол и т.н.), а лицето, вземащо решение за правилното внедряване, трябва да бъде преместено по-високо във веригата на отговорност.
За да илюстрираме това в примера с StorageService, ще използваме модел на поведенчески дизайн, наречен Strategy.
Ако погледнете внимателно ред 32 и след това редове 38–40, можем да заключим, че обектът StorageService сега е „заключен“, затворен за модификация и отворен за разширение. Редове 38–40 ни показват, че можем да добавим колко нови методи за съхранение са ни необходими и да не променяме кода вътре в StorageService.
Сега отново сме на път за чиста архитектура с проста промяна на кода, продиктувана от модел на проектиране.
Тъй като една картина струва хиляда думи, ще осигуря визуално представяне на това как една проста промяна в кода има последици на толкова много нива, ако кодовата база не е била проектирана и изградена правилно за мащабируемост.
Благодарим, че прочетохте!
Очаквайте за още.
