Nyílt/zárt elv

A nyílt/zárt elv a számítógép-programozásban a SOLID-alapelvek egyike (Single responsibility principle, Open/closed principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle), ezek megalkotója Robert C. Martin, a „tiszta kód mozgalom” vezérszónoka. Azt mondja ki, hogy a program forráskódja legyen nyitott a bővítésre, de zárt a módosításra. Eredeti angol megfogalmazása: “Classes should be open for extension, but closed for modification”.

A nyílt/zárt elv fogalma

Egy kicsit szűkebb értelmezésben úgy fogalmazhatnánk, hogy az osztályhierarchiánk legyen nyitott a bővítésre, de zárt a módosításra. Ez azt jelenti, hogy új alosztályt vagy egy új metódust nyugodtan felvehetünk, de meglévőt nem írhatunk felül. Ennek azért van értelme, mert ha már van egy működő, letesztelt, kiforrott metódusunk, és azt megváltoztatjuk, akkor több hátrányos dolog is történhet: a változás miatt az eddig működő ágak hibássá válhatnak, illetve a változás miatt a tőle implementációs függőségben lévő kódrészek megváltoztatására is szükség lehet.

Példakód C# nyelven

Kódunkban az if ... else if szerkezet jelenléte gyakran arra utalhat, hogy nem tartottuk be ezt az elvet, ezért a változtatást úgy vezettük be a kódunkba, hogy újabb ágat adtunk a meglévők mellé (vagyis megsértettük a módosításra vonatkozó zártság követelményét). Ez például egy árak számítását végző program esetében fordulhat elő, ahol különféle feltételektől függően eltérő árképzési stratégiára van szükség. Ha új árszámítási módszert kell megvalósítanunk, akkor egy újabb ág helyett a Védett változatok nevű GRASP-minta alkalmazásával, absztrakt osztály segítségével, egy interfészt hozhatnánk létre az árképzés miatt, és különböző alosztályok segítségével a polimorf viselkedést kihasználva implementálhatóak a konkrét árképzési stratégiák.

Példakód (C#)

abstract class Osztályzat{public abstract void Osztályoz(); }
      
class Ötös : Osztályzat
{
    public override void Osztályoz() { //ötös osztályzatot ad }
}
      
class Négyes : Osztályzat
{
    public override void Osztályoz() { //négyes osztályzatot ad }
}
 
class OsztályzatAdás
{
    public void OsztályozOsztályzat(Osztályzat a) {a.Osztályoz();}
}

Példakód magyarázata

A fenti példában bevezettünk egy közös őst, az absztrakt Osztályzatot. A konkrét osztályzatok csak felülírják az ős absztrakt Osztályoz metódusát és kész is az új gyermek. Ebből akárhányat hozzáadhatunk, a meglévő kódot nem kell változtatni. Tehát itt betartjuk az OCP-elvet. A közös absztrakt ős másik előnye az, hogy ha a kódban a gyermekosztály példányait csak az közös ős felületén keresztül használjuk, akkor ezzel betartjuk a GOF1 ajánlást is. Az OCP-elv alkalmazására nagyon szép példa a stratégia és a sablonfüggvény programtervezési minta. Az utóbbi hook metódusokra is ad példát.

Kapcsolódó szócikkek

• Egyetlen felelősség elve
• Robert C. Martin
• Programtervezési minta
• Objektumorientált programozás

Források

• Gamma, Helm, Johnson & Vlissides. Design Patterns (könyv). Addison-Wesley (1994). ISBN 0-201-63361-2 
• Dr. Kusper Gábor. Programozási technológiák (jegyzet) (2015) 
• Robert C. Martin. Túlélőkönyv programozóknak, Hogyan váljunk igazi szakemberré?. Kiskapu Kft. (2011). ISBN 9789639637863 
• Robert C. Martin. Clean Code (Tiszta kód, az agilis szoftverfejlesztés kézikönyve) (2010). ISBN 9789639637696