S.O.L.I.D. – Objektum orientált tervezési elvek 3. LSP

A sorozat részei:

SRP, OCP, LSP, ISP, DIP

Kétségkívül a legérdekesebb elv következik: a Liskov helyettesítés (Liskov Substitution Principle). Az állításunk a következő:

Ha S altípusa T-nek, akkor minden olyan helyen ahol T-t felhasználjuk S-t is minden gond nélkül behelyettesíthetjük anélkül, hogy a programrész tulajdonságai megváltoznának.

Fordítsuk le ezt kevésbé hivatalos nyelvre:

Ha S osztály T osztály leszármazottja, akkor S szabadon behelyettesíthető minden olyan helyre (paraméter, változó, stb…), ahol T típust várunk.

Ez nagyon úgy hangzik, mintha a polimorfizmusról beszélnénk, egy apróságtól eltekintve: a második definícióból direkt kihagytam a programrész tulajdonságairól szóló részt, ugyanis épp ez lesz a lényeg.

Nézzünk egy egyszerű, ám annál híresebb példát: Kör-Ellipszis probléma:

class Shape { }

class Ellipse : Shape
{
    public double MajorAxis { get; set; }
    public double MinorAxis { get; set; }
}

class Circle : Ellipse
{

}

Az osztályhierarchiában a Kör az Ellipszisből származik, lévén annak egy speciális esete. Na most, ha a fenti állításokat figyelembe vesszük, akkor egy rendkívül érdekes problémával nézünk szembe: tegyük fel, hogy egy olyan függvényt készítünk, amely egy ellipszis tengelyeit is módosítja. Ugye fönt kimondtuk, hogy ilyenkor ezt a függvényt bármely Kör objektumra is meghívhatjuk és most jön a lényeg: mi történik, ha egy Kör objektum tengelyei (az Ellipszisből származik, szóval nincs szigorúan vett sugár) megváltoznak?

Azt bátran elmondhatjuk, hogy onnantól megszűnik Kör lenni, elméletileg legalábbis, de maga a Kör objektum – immár hibásan – még ugyanúgy létezik.

Van-e megoldás? Gyors ötlet: legyenek a tengelyekhez tartozó propertyk virtuálisak, a Kör osztályban pedig takarjuk el őket. Kár, hogy ezzel ugyanúgy ellentmondunk a szabálynak, hiszen ekkor az előbbi függvényt meg sem hívhatjuk. Sakk-matt.

A probléma ott van, hogy azt hisszük, hogy a Kör valójában egy Ellipszis. Ez az állítás matematikailag valóban megállja a helyét, de most programot írunk, így más szempontból is meg kell néznünk a tényeket. Az igazság az, hogy bár a Körnek vannak Ellipszisre emlékeztető tulajdonságai, de valójában máshogy viselkedik, nem tudjuk vele betartatni az Ellipszisre vonatkozó szabályokat.

A megoldás az, hogy nincs “igazi” megoldás, de vannak lehetőségeink. A legegyszerűbb, hogy – mivel egyszerű típusról van szó – legyenek az objektumaink immutábilisek, vagyis minden olyan esetben amikor az objektumot megváltoztatnánk, új objektum keletkezik, ekkor nyilván lehetőségünk van szabályozni, hogy milyen típussal szeretnénk dolgozni.

Egy másik “megoldás”, hogy egyáltalán nem vesszük bele a Kört a hierarchiába, helyette mindig Ellipszist használunk (pl. nézzük meg a .NET grafikus felülethez tartozó osztályait, nem fogunk speciálisan Kör osztályt találni).

Itt most tegyünk egy kis kitérőt! Van az informatikának egy területe, amelyet helyességbizonyításnak hívnak, ami azzal foglalkozik, hogy matematikai eszközökkel bizonyítja, hogy egy program helyesen működik vagy sem. Ennek a tudományágnak az egyik alapját a Hoare logika képezi, innen fogunk néhány dolgot kölcsönvenni. Vegyük az alábbi kifejezést:

{P}C{Q}

Legyen P a kiinduló állapotra alkalmazott kikötés (nevezzük előfeltételnek, precondition), C egy művelet, Q pedig a művelet hatására létrejött állapot irányában támasztott feltétel (utófeltétel, postcondition). Mit jelent ez a gyakorlatban?

Nézzünk egy példát! Tegyük fel, hogy a műveletünk az osztás, ugye azt mindenki tudja, hogy nullával nem osztunk, vagyis az előfeltételben ki kell kötnünk, hogy az osztónak szánt paraméter értéke nem lehet nulla. Tehát az előfeltételnek igaznak kell lennie, különben az adott programrész viselkedése instabil lesz.

Ugyanígy működik az utófeltétel is, de ő a művelet végrehajtása utáni állapotra vonatkozik, például ha faktoriálist számolunk, akkor tudjuk, hogy az eredmény minden esetben nagyobb vagy egyenlő eggyel, vagyis ezt a feltételt tesszük az utófeltételbe.

Végezetül az invariáns a kettő kombinációjának nevezhető, vagyis olyan állítás, amely a művelet előtt és után is érvényes. Tökéletes példa egy Kör objektumokon végzett művelet, ekkor az invariánsban megmondhatjuk, hogy a Kör tengelyei (ugye még mindig egy Ellipszis leszármazottról van szó) egyenlők kell legyenek a művelet előtt és után is.

Ez eddig nagyon érdekes, de mi köze van a Liskov helyettesítéshez? Nagyon is sok, ezt az elvet a következő szabályokon keresztül lehet betartani:

– Az előfeltétel nem lehet erősebb a leszármazott osztályokban

– Az utófeltétel nem lehet gyengébb a leszármazott osztályokban

Nézzük meg, hogy ez hogy működik a gyakorlatban! Térjünk vissza az eredeti Kör-Ellipszis példára: az Ellipszis osztály egy ki nem mondott utófeltétele, hogy a tengelyeket tetszés szerint módosíthatjuk. Ha a Kör osztályban megmondjuk, hogy ezt talán mégsem szeretnénk, azzal meggyengítjük az eredeti utófeltételt, vagyis a Kör osztályt ilyen módon nem használhatjuk Ellipszisként.

Az előfeltétel/utófeltétel/invariáns trió és társaik egyébként a Design By Contract nevű fejlesztési “módszertanban” is megtalálhatóak, sőt a .NET beépítve tartalmazza a szükséges eszközöket is.

Rendben, eddig elég nyilvánvaló volt a probléma, hoztam egy életszerűbb példát is. Vegyük a következő metódust:

public void SaveEntities(IEnumerable<IEntity> entityList)
{
    foreach (IEntity entity in entityList)
    {
           DBconnection.Save(entity);
    }
}

Ugye vannak mindenféle entitásaink, amelyeket ugyanabban a metódusban mentünk el az adatbázisba. Na most, tegyük fel, hogy megkérnek minket, hogy egy adott entitástípus esetében a mentés előtt végezzünk el egy másik műveletet, ekkor az eredmény:

public void SaveEntities(IEnumerable<IEntity> entityList) {     foreach (IEntity entity in entityList)     {         if (null != entity as SomeEntity)         {             DoSomeJob(entity);         }         DBconnection.Save(entity);     } }

public void SaveEntities(IEnumerable<IEntity> entityList)
{
    foreach (IEntity entity in entityList)
    {
        if (entity is SomeEntity)
        {
            DoSomeJob(entity);
        }

        DBconnection.Save(entity);
    }
}

Most lapozzunk vissza a poszt elejére és nézzük meg, hogy mi a szabály vége: “anélkül, hogy a programrész tulajdonságai megváltoznának.” Az eredeti szövegben ezt úgy fogalmazták meg, hogy az adott programrész nem tudja, hogy egy leszármazottal van dolga.

Nyilvánvaló, hogy ezt a metódusunkban megszegtük, hiszen minden új funkcióhoz típusellenőrzésre van szükség, ami se nem elegáns, se nem hatékony. Tehát az ökölszabályunk a következő: ha egy adott programrész típusellenőrzésre épül akkor jó eséllyel valamit rosszul csinálunk. Egyúttal vegyük észre, hogy a fenti kód alapelve nagyon hasonlít arra amit az Open-Closed elvnél elkövettünk, és valóban; a Liskov helyettesítés annak egy speciális esete.

Mi legyen a megoldás? Ehhez meg kell néznünk, hogy miért alakult ki egyáltalán a probléma: ugyanúgy akartuk kezelni az összes IEntity-t megvalósító osztályt. Ötlet: ne tegyük. Vagyis megtehetjük, hogy az egyes altípusokat külön-külön metódussal/osztállyal dolgozzuk fel, pl. a Visitor vagy a Repository tervminták alapján.

‹ S.O.L.I.D. – Objektum orientált tervezési elvek 2. OCP

S.O.L.I.D. – Objektum orientált tervezési elvek 4. ISP ›

Tagged with: OOP
Nincs kategorizálva kategória