Nyitva/zárt elv

A Wikipédiából, a szabad enciklopédiából
Ugrás a navigációhoz Ugrás a kereséshez

A nyitva/zárt elv a SOLID alapelvek része (Single responsibility principle, Open/closed principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle), ezek megalkotója Robert C. Martin, a clean code „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”.

Nyitva/zárt elv fogalma[szerkesztés]

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 az 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[szerkesztés]

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élda kó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[szerkesztés]

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.

Lásd még[szerkesztés]

Robert C. Martin
Programtervezési minták
Objektumorientált programozás

Források[szerkesztés]

  • 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)