Публикувано на: 4 август, 2017В рамките на 5 седмици ще ви представим поредица от 5 статии, предназначена за програмисти, които искат да повишат нивото на качество в работата си. Следващите принципи, са само началото на поредица от различни добри практики и насоки, формулирани от едни от най-опитните в бранша. Голяма част от тях са описани в детайли в книгата на Робърт Мартин – “Agile Principles, Patterns, and Practices in C#”. Петте принципа в тези статии засягат ежедневните предизвикателства, пред които е изправен всеки един програмист и като такъв е добре, да е запознат с правилните начини за справянето с тях. Спазването на всеки един от принципите, е признак на професионализъм, и ще доведе до по-добър дизайн на дадена система. Това е част 3-та от поредицата от петте статии.
Част I-ва прочетете тук: SOLID принципи за обектно ориентиран софтуерен дизайн – Част I
Част II-ра прочетете тук: SOLID принципи за обектно ориентиран софтуерен дизайн – Част II
The Liskov Substitution Principle (LSP)
“Подтиповете трябва да са взаимнозаменяеми с техните базови типове.”
Класическият пример за правилно прилагане на Liskov Substitution Principle
е така нареченият проблем “квадрат-правоъгълник”. Да си представим, че трява да опишем тези два обекта и връзките между тях, в приложение, което работи с геометрични фигури. Имаме създаден клас правоъгълник, който изглежда така:
В математиката квадратът е вид правоъгълник и това може лесно да ни подведе и да направим така че класът квадрат да наследи класа правоъгълник. Това решение обаче ще доведе до няколко проблема. Първият е, че класът правоъгълник има две свойства, които отговарят за запазването на стойностите на страните А и В, а класът квадрат има нужда само от едно и за двете си страни. В така дадената имплементация, класът квадрат ще трябва да изглежда така:
По този начин, частично се решава проблемът с различния вид информация, която се пази във фигурите. Това се постига като, всеки път когато се задава стойност на свойство за страна на квадрата, тази стойност се копира и за другото негово свойство за страна. Вторият проблем е, че няма как да се направи конструктор за класа квадрат, който да има само един параметър. Това е в следствие на създадения конструктор с два параметъра в класа правоъгълник. Единственото решение е една и съща стойност да се подаде два пъти. Проблеми могат да възникнат и при употребата на тези два класа. Нека разгледаме следния метод, в който се увеличават страните на даден правоъгълник с произволни стойности:
Loading …
София
На дадено място в приложeнието срещаме употреба на метода описан по-горе:
Тъй като класът квадрат наследява класа правоъгълник можем да създадем колекция, съдържаща правоъгълници, а в нея да имаме както правоъгълници така и квадрати. В този момент употребата на дадения метод за увеличаване на страните произвежда грешен резултат. Големината на страните на квадратите ще бъдат манипулирани неправилно. За да се избегнат подобни странични ефекти Liskov Substitution Principle задължава всички подтипове да са напълно заменяеми с техните базови типове, независимо от ситуацията. Също така допълва, че не всички връзки между обекти могат да се представят директно чрез наследяване. Наследяването в програмирането се отнася по-скоро до наследяване на поведение, отколкото до нещо друго. Ако поведението на два обекта трябва да е различно, то те не трябва да имат наследяване помежду си. Liskov Substitution Principle е един от най-важните фактори за постигане на 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
