Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

AZ OBJEKTUM-ORIENTÁLT TERVEZÉSI ALAPELVEK KRITIKAI VIZSGÁLATA Kusper Gábor, EKF, MatInf Intézet Márien Szabolcs, Wit-Sys ZRt.

Hasonló előadás


Az előadások a következő témára: "AZ OBJEKTUM-ORIENTÁLT TERVEZÉSI ALAPELVEK KRITIKAI VIZSGÁLATA Kusper Gábor, EKF, MatInf Intézet Márien Szabolcs, Wit-Sys ZRt."— Előadás másolata:

1 AZ OBJEKTUM-ORIENTÁLT TERVEZÉSI ALAPELVEK KRITIKAI VIZSGÁLATA Kusper Gábor, EKF, MatInf Intézet Márien Szabolcs, Wit-Sys ZRt.

2 Tartalom  Tervezési alapelvek:  GOF1, GOF2, SRP, OCP  Egy új elv: DLP – Decision Lifting Principle  Néhány összefüggés a régi és az új elvek közt:  OCP ~ DLP  GOF2 ~ DLP  Összefoglaló

3 GOF könyv

4 GOF1  „Program to an interface, not an implementation!”  „Programozz felületre implementáció helyett!”

5 GOF1 megszegése 1.  import java.util.*;  public class MyHashSet extends HashSet{  private int addCount = 0;  public boolean add(Object o){  addCount++;  return super.add(o);  }  public boolean addAll(Collection c){  addCount += c.size();  return super.addAll(c);  }  public int getAddCount(){ return addCount; }  }

6 GOF1 megszegése 2.  import java.util.*;  public class Main {  public static void main(String[] args){  HashSet s = new MyHashSet();  String[] abc = {"a","b","c"};  s.addAll(Arrays.asList(abc));  System.out.println(s.getAddCount());  }

7 GOF1 következményei  Kerülni kell az öröklést, vagy legalább  Kerülni kell a super (C#-ban base) hívásokat.  A kliens csak a szolgáltató felületét ismerje. azaz  A szolgáltatás egy absztrakt osztály / interface mögött legyen. azaz  Minden hierarchia tetején egy absztrakt osztály legyen.

8 GOF2  „Favor object composition over class inheritance!”  „Használj objektum összetételt öröklés helyett, ha csak lehet!”  Öröklés: IS-A kapcsolat, könnyen érthető  Objektum összetétel: HAS-A kapcsolat, bonyolultabb  Objektum összetétel fajtái:  Aggregáció: Ha meghal a gitáros, nem temetik vele a gitárját.  Kompozició: Ha meghal a gitáros, vele temetik a gitárját.

9 Az öröklődés mindig kiváltható objektum összetétellel class A { public void m1() { Console.Write("hello"); } class B : A { public void m2() { m1(); } class Program { static void Main(string[] a) { B b = new B(); b.m2(); } class A { public void m1() { Console.Write("hello"); } class B { A a = new A(); public void m2() { a.m1(); } class Program { static void Main(string[] a) { B b = new B(); b.m2(); }

10 GOF2 következményei  Öröklést kerülni kell.  Rugalmasabb, de nehezebben érthető lesz a kód.  Lehetőséget add arra, hogy futási időben injektáljunk be felelőséget.  A GOF2-nek ismerjük az előnyeit és hátrányait, de nem tudjuk, mikor kell használni!!!

11 Tiszta kód

12 SRP - Single Responsibility Principle  „A class should have only one reason to change”  „Az osztályoknak csak egy oka legyen a változásra”  Programozás technológia elve:  „A program kódja állandóan változik”  Az SRP azt mondja ki, hogy egy változás hatására csak egy osztály változzon meg.

13 SRP következményei  Kerüljük a MacsKuty típusú osztályokat:  Akkor is megváltozik, ha kiderül, hogy a Kutya nem csak ugatni tud,  És akkor is megváltozik, ha kiderül, hogy a Macska nem csak egerészni tud.  Sok-sok unit teszt alkalmazása:  TDD – Test Driven Develpment  Használjuk Aspektus-Orientált Programozást  pl. logolásra, jogosultság ellenőrzésre

14 Egy összefüggés: SRP ~ GOF1  A GOF1 megszegése gyakran az SRP megszegéséből ered:  Ha egy osztály nem teljesen fedi le a fellelőség köreit, akkor egy másik osztálynak kell megvalósítani ezeket. Ehhez viszont ismernie kell az eredeti osztály megvalósítását, tehát megszegjük a GOF1-et.

15 OCP - Open-Closed Principle  „Classes should be open for extension, but closed for modification”  „Az osztályok legyen nyitottak a bővítésre, de zártak a módosításra” azaz  „Az osztály hierarchia legyen nyitott a bővítésre, de zárt a módosításra”

16 OCP megszegésére utaló jelek  Bonyolult if – else if vagy switch szerkezetek.  Override használata.  Csak absztrakt és hook metódusok felülírását engedi.

17 OCP megszegése  class Alakzat {  public const int TEGLALAP = 1; public const int KOR = 2; int tipus;  public Alakzat(int tipus) { this.tipus = tipus; }  public int GetTipus() { return tipus; }  }  class Teglalap : Alakzat{Teglalap():base(Alakzat.TEGLALAP){}}  class Kor : Alakzat{ Kor():base(Alakzat.KOR){} }  class GrafikusSzerkeszto {  public void RajzolAlakzat(Alakzat a) {  if (a.GetTipus() == Alakzat.TEGLALAP) RajzolTeglalap(a);  else if (a.GetTipus() == Alakzat.KOR) RajzolKor(a);  }  public void RajzolKor(Kor k) { /* … */ }  public void RajzolTeglalap(Teglalap t) { /* … */ }  }

18 DLP - Decision Lifting Principle  „Öröklést csak döntés kiemelésre használj!”  „Use inheritance only for decision lifting!”  DLP megszegésére utaló jelek:  Ismétlődő if – else if szerkezetek.  Ismétlődő switch szerkezetek.

19 DLP megszegése  class Alakzat {  public const int TEGLALAP = 1; public const int KOR = 2; int tipus;  public Alakzat(int tipus) { this.tipus = tipus; }  public int GetTipus() { return tipus; }  }  class Teglalap : Alakzat{Teglalap():base(Alakzat.TEGLALAP){}}  class Kor : Alakzat{ Kor():base(Alakzat.KOR){} }  class GrafikusSzerkeszto {  public void RajzolAlakzat(Alakzat a) {  if (a.GetTipus() == Alakzat.TEGLALAP) RajzolTeglalap(a);  else if (a.GetTipus() == Alakzat.KOR) RajzolKor(a);  }  public void RajzolKor(Kor k) { /* … */ }  public void RajzolTeglalap(Teglalap t) { /* … */ }  }

20 DLP betartása  abstract class Alakzat{ public abstract void Rajzol(); }  class Teglalap : Alakzat {  public override void Rajzol() { /* téglalapot rajzol */ }  }  class Kor : Alakzat {  public override void Rajzol() { /*kört rajzol */ }  }  class GrafikusSzerkeszto {  public void RajzolAlakzat(Alakzat a) { a.Rajzol(); }  }  class Program {  public static void Main(String[] args) {  Alakzat alak = new Kor();  (new GrafikusSzerkeszto ()). RajzolAlakzat(alakzat);  }}

21 Összefüggés az OCP és a DLP közt  Az OCP azt mondja, hogy kerüljük a bonyolult if – else if szerkezeteket.  A DLP azt mondja, hogy kerüljük az ismétlődő if – else if szerkezeteket. Ugyanakkor meg is mondja, hogyan szüntessük meg az ismétlődést:  Döntéskiemelésselű  A bonyolult if – else if szerkezetek is döntéskiemeléssé degradálhatok egyszerű példányosítássá.

22 Összefüggés a GOF2 és a DLP közt  GOF2: „Használj objektum összetételt öröklés helyett, ha csak lehet!” azaz  Hacsak lehet ne használj öröklést!  DLP: „Öröklést csak döntés kiemelésre használj!”  A DLP pontosítja a GOF2-t, hiszen megmondja, mikor kell öröklést használni, egyébként pedig objektum összetételt kell használni.

23 Összefoglalás  Nagyon sok tervezési alapelv van.  Van amelynél tudható, hogy milyen esetben hogyan kell átalakítani a programot: GOF1, OCP, DLP.  Van amelynél nem tudható, hogy kell-e használni a konkrét esetben, habár sok elméleti előnnyel jár: GOF2, SRP.  Bevezettünk egy új tervezési alapelvet, a DLP-t, amely megmondja mely esetekben nem használandó a GOF2.

24 KÖSZÖNÖM A FIGYELMET! címek: Kusper Márien

25 Néhány összefüggés  Ha úgy sértjük meg az SRP-t, hogy egy osztály nem teljesen fedi le a fellelőség köreit, akkor egy másik osztálynak kell megvalósítani ezeket. Ehhez viszont ismernie kell az eredeti osztály megvalósítását, tehát megszegjük a GOF1-et.  Ha úgy sértjük meg az SRP-t, hogy egy osztály több felelőségi kört is lefed, akkor megszegjük a GOF2-öt, mert a két felelőséget szét lehetne szedni két osztályra, amit egy harmadik foghatna össze objektum összetétellel.


Letölteni ppt "AZ OBJEKTUM-ORIENTÁLT TERVEZÉSI ALAPELVEK KRITIKAI VIZSGÁLATA Kusper Gábor, EKF, MatInf Intézet Márien Szabolcs, Wit-Sys ZRt."

Hasonló előadás


Google Hirdetések