+
Вход

Въведи своя e-mail и парола за вход, ако вече имаш създаден профил в DEV.BG/Jobs

Забравена парола?
+
Създай своя профил в DEV.BG/Jobs

За да потвърдите, че не сте робот, моля отговорете на въпроса, като попълните празното поле:

73+36 =
+
Забравена парола

Въведи своя e-mail и ще ти изпратим твоята парола

SOLID принципи за обектно ориентиран софтуерен дизайн – Част II

В рамките на 5 седмици ще ви представим поредица от 5 статии, предназначена за програмисти, които искат да повишат нивото на качество в работата си. Следващите принципи, са само началото на поредица от различни добри практики и насоки, формулирани от едни от най-опитните в бранша. Голяма част от тях са описани в детайли в книгата на Робърт Мартин – “Agile Principles, Patterns, and Practices in C#”. Петте принципа в тези статии засягат ежедневните предизвикателства, пред които е изправен всеки един програмист и като такъв е добре, да е запознат с правилните начини за справянето с тях. Спазването на всеки един от принципите, е признак на професионализъм, и ще доведе до по-добър дизайн на дадена система. Това е част 2-ра от поредицата от петте статии.
Част I-ва прочетете тук: SOLID принципи за обектно ориентиран софтуерен дизайн – Част I
 

The Open/Closed Principle (OCP)

“Софтуерните елементи (модули , класове, функции), трябва да са отворени за разширение, но затворени за промяна.”

 
Когато една промяна в кода води до множество промени на други места в него, това значи че дизайнът, който сме избрали е “чуплив” (не се поддава на промяна). Спазването на Open/Closed Principle води до такъв дизайн, че една промяна не предизвиква други промени. Ако Open/Closed Principle е приложен както трябва – нови промени в системата се постигат чрез добавяне на код, а не чрез промяна на стария, който вече се използва някъде. Това може да изглежда като невъзможно за постигане, но стремежът към него е много важен.
Един пример за това може да бъде следната задача:
Трябва да направим приложение, което да може да изрисува кръгли и квадратни фигури на екрана. Така поставена задачата има краен брой фигури, за това една възможна реализация, може да изглежда по следния начин:

Това решение е напълно достатъчно до момента, в който не се наложи да добавим нов вид фигури за изчертаване. За да ги добавим, ще е необходимо да добавим нов тип фигура в енумератора и да добавим още едно условие в логиката за изрисуване. Това ще се повтаря всеки път, когато се добавят нови изисквания към приложението. За да бъде предотвратени многократните промени трябва да се приложи Open/Closed Principle. Новият дизайн трябва да изглежда така:

Днес те питаме…

Как настоящият ИТ пазар влияе на желанието ти за смяна на работа?
Loading ... Loading …


В тази имплементация добавянето на нова фигура, няма да изисква никакви промени във вече написания код. Единственото, което трябва да се направи, за да се добави нова фигура, е да се добави нов клас, който имплементира интерфейса.
В много отношения Open/Closed Principle е в основата на добрия обектно-ориентиран дизайн. Спазването на този принцип е от голямо предимство, когато искаме да постигнем гъвкавост на системата, лесна поддръжка и преизползваем код. Не е добра идея обаче такъв вид абстракция да се прилага на всяка част от приложението. Тя трябва да е в следствие на нови изисквания към системата или изменения в текущите. Използването на ненужна абстракция е също толкова лошо, колкото и липсата на абстракция.
 


 

За автора: Костадин Капсъзов

 
– Костадин Капсъзов се занимава професионално с програмиране от 2012 година.
– Работил е за над 10 различни български и международни компании, като трупа опит и знания в различни сфери на бизнеса.
– Успешно участва в над 13 проекта, използващи различни програмни езици като: C#, C++, Java, Python, JavaScript, Objective-C и др.
– В момента е програмист в екипа „Нови разработки и Иновации“ на българската технологична компания UltraPlay.
– От 2014 г. Започва активно да се интересува от „Software Craftsmanship“ – подход за разработка на софтуер, който набляга на качеството на програмните уменията на софтуерните разработчици. Около този подход се основава гилдия, която споделя идеите, описани от Анди Хънт, в книгата „The Pragmatic Programmer“ и книгата на Дейв Томас „Software Craftsmanship“. Тези идеи описват разработката на софтуер като занаят, подобен на занаятите практикувани от занаятчийските гилдии през Средновековековието.
 


 
Стани част от потребителските групи на DEV.BG. Виж всички потребителски групи и избери най-интересните за теб.
Визия: Личен архив
Прочети още:
6 от най-популярните Machine Learning алгоритми – приложения и възможности
Какво означава една система да е „reactive“? Основна концепция на Reactive programming