Просто като вишист да обясня. Една програма трябва да върне същият резултат ако в нея заменим инстанциите на даден клас с негов наследник. Полиморфизмът е средство да се изпълни това.
Много хора се бъркат, защото масово старите програмните езици не правят разлика между inheritance и subtyping. Правилото на Лисков, служи да ти напомни да ползваш subtyping, защото inheritance е дете на дявола. Поради тази причина в съвременните езици няма inheritance, има само subtyping.
Какво е subtyping: отнася се за съвместимостта на интерфейсите - Ако Б е подтип на А, то върху Б трябвада може да извикаш всяка функция, която може да извикаш на А, като не променяш контракта. На джаварски може да се каже, че събтайпинга е да имплементираш някъв интерфейс.
Какво е inheritance: отнася се за преизползването на код - примерно функциите на тип Б са имплементирани чрез функциите на тип А. Ясно е че ако наследиш някакъв клас той получава достъп до protected + public методите на родителския клас. До голяма степен (без protected) същото се постига и чрез композиция, но с добавения плюс, че не си замърсяваш типа.
Прост пример: имаш клас 2ДТочка(х, у). Може да направиш 3ДТочка като наследиш 2ДТочка и добавиш още едно поле за Z. Обаче така чупиш контракта на hashcode/equals. Езика ти позволява да подадеш указател към 3ДТочка, там където се очаква указател към 2Дточка, защото имаш отношение is-a: демек 3Д точката е 2Д точка. Виждаш ли проблема ?
Да върне същия резултат или просто да върви? Щото тук цък втория пример показва как с базов клас и с наследник програмата показва различни резултати.
D-то поне в low ceremony езиците с така наречения duck typing (което отново НА ПРАКТИКА е лицето на полиморфизма, просто от малко по-друг ъгъл) също е stating the obvious но в езици като Java и C# е смислено напомняне че ако ползваш само IEnumerable функционалност например не бива да да шибаш по-специализиран интерфейс за тип на параметър или пък конкретна реализация.
А Лисков казва точно това - подаването на инстанция на наследник не трябва да да чупи кода както синтактично така и семантично което ако си наясно с по-общата идея на полиморфизма е очевидно - всеки наследник или добавя или имплементира базова функционалност по специфичен начин, но това трябва да не променя желаното поведение на програмата, тоест децата да поддържат ПОНЕ нещата поддържани от родителите а тези които ги правят по специфичен начин да са семантично коректни, не просто овъррайднатият метод да е синтактично коректен но и смислово да прави квото базата е посочила като път към светлото бъдеще
Иба, що всички колеги не са като теб...
Аз нямам против да съм грешен, стига докато греша да ми плащат.
Мани грешките, говоря че с теб се спори приятно и смислено, кой не греши
Очевидно не разбираш и D-то, и не, не е Dick. D-то е Dependency Inversion (не Injection, за което си мислиш) и няма общо със спрингове и еджъбъта
Моите колеги, те са безгрешни. Носят фланелки от конференции, i test on production, tell me more about your monolith и подобни. ПР при нас е или си съгласен с тях или си търси нова работа.
Общо взето доста програмисти има като тях. Вечер жените им ги стимулират с дилдота докато бистрят новата гениална архитектура.
Ти да не бачкаш в бангладешка фирма бе, кви са тия изроди? Аз тук носех девелоперски надписи, гледаха ме като изтребител
Естествено че един правоъгълник ще се изчертава по различен начин от окръжност или резултатът от Adder calc ще е различен от резултатът на Multiplier calc (и двамата наследника на база за сметки с два операнда).
Но поведението на програмата, да се изчертае неква фигура или сметне неква сметка с два операнда трябва да е едно и също по смисълът вложен в самата абстракция
Е хамериканци са, но бачкам дефакто с украинци, поляци, хървати и тук таме българи. Украинците са най-тъпата нация евър.
Тук можем да навлезем в един интересен спор какво значи "смисъл вложен в абстракцията". Ако двата метода са с леко различен смисъл тогава солидни ли сме или не?
Т.е. имаме си 3 думички ено и също нещо. Лисков, open-closed principle, и полиморфизъм?
Ами не, не виждам проблема.
3Д точката наистина е 2Д точка. Не само от програмистка, но и от математическа гледна точка.
Тоест, това, което работи с 2Д точка, трябва коректно да работи и с 3Д точка.
Запзването на интейрфейсния инвариант не е ли очевидно от самата идея на полиморфизма независимо дали става въпрос за йерархия интерфейси или класове?
Тоест семантично да се подават вместо и сравняват три де точки с две де точки е некоректно щото три де точката 'не знае' как да се изчертае в две де вселена понеже няма достатъчно информация кое измерение 'да игнорира', тоест в случая самата направия на три де точката като наследник на две де точка е кофти дизайн стъпващ върху това че 'е то само още едно измерение, кво толко' и по-удачно би било да има изцяло отделен клас три де точка, две де точката не е is a три де точка БЕЗУСЛОВНО а само когато има наложено допълнителното ОГРАНИЧЕНИЕ да е недвусмислено откъде я гледаме
От програмистка точно по смисъла на Лисковия принцип не е :)
Поставя ДОПЪЛНИТЕЛНО изискване (освен ако дизайнът не е нарочно направен да предполага че ако се подава три де точка вместо две се гепват конкретни две компоненти което пък е калпав дизайн щото е трудно да се направи така че да не е само неочевидна конвенция).
Объркването идва от това че ПОВЕЧЕТО информация носена от три де точката всъщност прави ИНТЕРФЕЙСЪТ три де точка ПО-ОГРАНИЧАВАЩ въпреки че привидно 'само' ДОБАВЯ :)
inheritance и subtyping-a ми се губеха, но добре, че го споменахте, да се зачета по темата. И аз си мислех, че едното == другото. +1 за форума, дълго да има такива теми.
Наследяването на класове е типчният пример за 'пътят към ада е постлан с добри намерения' щото често се ползва просто като паразитно 'удобство' базирано на повърхностни аналогии, оопетто е пълно с такива 'удобства' :)
Ей деба, имам данни да стана чуден умнокрасив оопе хейтър, трябва да попия повече от тоя образ и ще съм зловещо ефпи зомби