| dbo:abstract
|
- Az 1994-ben a Design Patterns: Elements of Reusable Object-Oriented Software (Programtervezési minták, Újrahasznosítható elemek objektumközpontú programokhoz) c. könyvben jelent meg. Az alapelv eredeti angol megfogalmazása: „Program to an interface, not an implementation”, azaz "Interfészre programozzunk, ne pedig implementációra! . Öröklődés során minden, az absztrakt műveletek konkretizálását végző osztály osztozik az interfészen, vagyis az interfészen változtatni az alosztályok illetve implementációs osztályok nem tudnak (még elrejteni sem tudják az öröklött/kapott műveleteket!). A konkrét osztályok „mindössze” új műveleteket adhatnak hozzá, illetve a meglévőket felüldefiniálhatják. Így viszont minden alosztály tud majd válaszolni az interfésznek megfelelő kérelmekre, amik lehetővé teszik, hogy a kliensek függetlenek legyenek az általuk felhasznált objektumok tényleges típusától (nem is kell őket ismerniük, így ez a lazán csatolás irányába tett nagy lépésként is értelmezhető), amíg az interfész megfelel a kliens által vártnak. A kliens így csak az interfésztől függ, és nem az implementációtól, vagyis anélkül cserélhetőek le a szolgáltatást nyújtó konkrét osztályok az interfész változatlanul hagyása melle Akkor kényszerülünk implementációra programozni, ha az osztály felelősségi körét rosszul határoztuk meg és egy osztály több felelősségi kört is lefed (ami ellent mond az egy felelősség elvének - SRP), vagy egy felelősséget sem fed le teljesen. Ha a kódunkban találunk olyan részt, amely egy másik osztályra implementációjától függ, akkor az hibás tervre utal. Ha implementációra programozunk és megváltozik az osztály, akkor a vele kapcsolatban álló osztályoknak is változniuk kell. Viszont, ha felületre programozunk, és megváltozik az implementáció, de a felület nem, akkor nem kell megváltoztatni a többi osztályt! Az interfészre való programozás előnyei közé tartozik a karbantarthatóságtt, hogy az a kliensekre bármiféle kihatással lenne. (hu)
- Az 1994-ben a Design Patterns: Elements of Reusable Object-Oriented Software (Programtervezési minták, Újrahasznosítható elemek objektumközpontú programokhoz) c. könyvben jelent meg. Az alapelv eredeti angol megfogalmazása: „Program to an interface, not an implementation”, azaz "Interfészre programozzunk, ne pedig implementációra! . Öröklődés során minden, az absztrakt műveletek konkretizálását végző osztály osztozik az interfészen, vagyis az interfészen változtatni az alosztályok illetve implementációs osztályok nem tudnak (még elrejteni sem tudják az öröklött/kapott műveleteket!). A konkrét osztályok „mindössze” új műveleteket adhatnak hozzá, illetve a meglévőket felüldefiniálhatják. Így viszont minden alosztály tud majd válaszolni az interfésznek megfelelő kérelmekre, amik lehetővé teszik, hogy a kliensek függetlenek legyenek az általuk felhasznált objektumok tényleges típusától (nem is kell őket ismerniük, így ez a lazán csatolás irányába tett nagy lépésként is értelmezhető), amíg az interfész megfelel a kliens által vártnak. A kliens így csak az interfésztől függ, és nem az implementációtól, vagyis anélkül cserélhetőek le a szolgáltatást nyújtó konkrét osztályok az interfész változatlanul hagyása melle Akkor kényszerülünk implementációra programozni, ha az osztály felelősségi körét rosszul határoztuk meg és egy osztály több felelősségi kört is lefed (ami ellent mond az egy felelősség elvének - SRP), vagy egy felelősséget sem fed le teljesen. Ha a kódunkban találunk olyan részt, amely egy másik osztályra implementációjától függ, akkor az hibás tervre utal. Ha implementációra programozunk és megváltozik az osztály, akkor a vele kapcsolatban álló osztályoknak is változniuk kell. Viszont, ha felületre programozunk, és megváltozik az implementáció, de a felület nem, akkor nem kell megváltoztatni a többi osztályt! Az interfészre való programozás előnyei közé tartozik a karbantarthatóságtt, hogy az a kliensekre bármiféle kihatással lenne. (hu)
|
