ugrás a tartalomhoz

Liskov substitution principle

eddig bírtam szó nélkül · 2012. Jún. 19. (K), 07.45
Ezen már régóta töröm a fejem: OK, ezek nem kőbe vésett szabályok, csak elvek, de ha ragaszkodom a S.O.L.I.D. L betűjének betartásához, akkor mi értelme a felüldefiniálható metódusoknak az OO nyelvekben? Hiszen ennek épp az a lényege, hogy az adott metódus működését megváltoztatom. Nem?
Mi az amit rosszul értelmezek?

Valahol erről már beszéltem valakivel, de nem találom, a memóriám meg... :-(

--------------------------------------------

(Itt találtam egy magyar leírást. Úgy látszik, az angolom hiányosabb, mint képzeltem. És a felfogóképességem is. Továbbra sem értem, de attól tartok, ezek után hiába próbálja bárki elmagyarázni, nem fogom megérteni. :-(
‹ Python egymásról lepattanó labdák Bekezdés eleji évszámnál Markdown sajátosság kikerülése? ›
 ■
1

Kulcsszo: correctness

sandornemeth · 2012. Jún. 19. (K), 09.36
A Wikipedia szerint ez a Liskov substitution principle:
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”.


Ez azt jelenti, hogy abban az esetben, hogyha feluldefinialsz egy leszarmazasban egy metodust, akkor kicserelve a szulo osztaly objektumat a gyermek osztaly objektumara, a program mukodese helyes marad. Az, hogy az adott metodus hogyan biztositja a program helyesseget, az csak es kizarolag a metodus feladata.
2

Ezek alapján, ha van egy

inf · 2012. Jún. 19. (K), 11.01
Ezek alapján, ha van egy HashSet-ed, ami csak egy bizonyos osztályú objektumot fogad el, akkor az már áthágja ezt a szabályt. Vagy tévednék?
3

Casting

sandornemeth · 2012. Jún. 19. (K), 13.03
Java-ban castinggal egy class hierarchyn meg tudod csinalni az alabbit HashSettel: 

class A {...}

class B extends A {...}

HashSet<A> set = new HashSet<A>();
B b = new B();
set.add(b);

// sot ez is jo
HashSet<B> bSet = new HashSet<B>();
A a = new B();
bSet.add((b) a)
4

equals() es hashCode()

sandornemeth · 2012. Jún. 19. (K), 13.05
Egyebkent erre a tipikus pelda java-ban szerintem az equals() es a hashCode() metodusok, amelyekkel minden objektum rendelkezik (hiszen mindenki a java.lang.Object leszarmazottja), viszont mindenki felulirhatja oket, es ettol a program mukodese nem valtozik - felteve hogy a felulirt metodusok megtartjak az equals es hashCode fuggvenyekre ervenyes tulajdonsagokat.
5

A nagyon formális

tgr · 2012. Jún. 21. (Cs), 20.56
A nagyon formális programozáselméletben ez úgy néz ki, hogy minden függvénynek vannak előfeltételei (az osztály felhasználójának csak úgy szabad a függvényt meghívnia, hogy a hívás előtt ezek teljesülnek) és utófeltételei (az osztály kiterjesztőjének csak olyan leszármazott függvényt szabad írnia, hogy ha a hívás előtt teljesültek az előfeltételek, akkor a hívás után teljesülnek az utófeltételek). Vö. design by contract.

A gyakorlatban egyszerűen csak arról van szó, hogy az alkalmazónak van valami elképzelése arról, hogy mit csinál az adott absztrakció (pl. egy cache-be ha beteszel egy elemet egy adott kulccsal, és később lekérdezed azt a kulcsot, akkor visszakapod a betett elemet), és az összes megvalósításnak ennek megfelelően kell viselkednie (legyen az fájl cache vagy db cache vagy bármi egyéb).

Még gyakorlatabban persze ez se igaz, az absztrakciók mindig eresztenek. Például ha memcached van a cache mögött, akkor néha beteszed az elemet, és nem jön ki belőle; vagy különféle implementációk különféle karaktereket fogadnak el a kulcsban. Ahogy a többi OOP alapelvnél, itt is tisztában kell vele lenni, hogy miért hasznos, és amikor nem az, akkor nem kell túl komolyan venni. Ha egy más által írt, publikus interfészhez írsz mások által használandó implementációt (teszem azt egy DB absztrakciós rendszerhez publikálsz egy új csatolót), akkor illik nagyon vigyázni, ha saját használatra dolgozol, akkor csak annyira, hogy magadat ne szivasd meg.