Публикувано на: 24 юли, 2017В рамките на 5 седмици ще ви представим поредица от 5 статии, предназначена за програмисти, които искат да повишат нивото на качество в работата си. Следващите принципи, са само началото на поредица от различни добри практики и насоки, формулирани от едни от най-опитните в бранша. Голяма част от тях са описани в детайли в книгата на Робърт Мартин – “Agile Principles, Patterns, and Practices in C#”. Петте принципа в тези статии засягат ежедневните предизвикателства, пред които е изправен всеки един програмист и като такъв е добре, да е запознат с правилните начини за справянето с тях. Спазването на всеки един от принципите, е признак на професионализъм, и ще доведе до по-добър дизайн на дадена система. Ето и първата от петте статии:
The Single-Responsibility Principle (SRP)
“Един клас трябва да има само една причина за промяна.”
За първи път този принцип е описан в работата на Том ДеМарко и Мейлир Джоунс. Те го наричат кохезия (cohesion) и го определят като, функционалната свързаност на елементите в един клас. Терминът идва от латинското cohaerere – слепвам, стоя заедно. Точно това описва и принципа – за елементите в един клас трябва да е естествено да “стоят заедно”. Ако няма причина дадена функционалност да е в класа, тя не трябва да стои там.
Това може да бъде показано със следния пример:
Имаме за задача да направим две приложения, които да използват споделена логика. След първоначалния анализ, е създадена следната UML диаграма показваща зависимостите в приложението:
От нея се разбира, че класът правоъгълници има две отговорности. Първата е чрез геометрична формула да смята лицето си, а втората – да знае как да се изчертае на екрана. Това е явно нарушение на Single-Responsibility Principle. Тези две отговорности нямат нищо общо. Проблемът е в това че, много по-често се налага многогократна промяна в начина за визуализация на един обект, отколкото в основната логика, участваща в него. По-добрият дизайн, в такава ситуация ще бъде методът за изчертаване на екрана, да се намира в друг клас, който да наследява базовия:
Loading …
Fully Remote
Hybrid
По този начин промените в начина на изчертаване няма да засегнат другата логика на класа правоъгълник. Това е основна цел при разработването на гъвкав дизайн – промените да не влияят една на друга. Single-Responsibility Principle е един от най-простите принципи, но и един от най-трудните за спазване. Намирането и разделянето на отговорност е в основата му, затова трябва да се отдели необходимото време за анализ на поставената задача. Могат да се дадат много примери за нарушаване на Single-Responsibility Principle, но едни от честите се намира в класове, които се наричат Utils, ServiceManager, CommonServicе (или нещо подобно). Функционалността в тях не е конкретна и винаги има повече от една причина за промяна. Такива класове са едно подходящо място за поправяне, когато започнем да прилагаме Single-Responsibility 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 алгоритми – приложения и възможности
Умен дом с openHAB и Eclipse SmartHome. Интервю с Димитър Иванов
