This HTML5 document contains 23 embedded RDF statements represented using HTML+Microdata notation.

The embedded RDF content will be recognized by any processor of HTML5 Microdata.

Namespace Prefixes

PrefixIRI
wikipedia-huhttp://hu.wikipedia.org/wiki/
dcthttp://purl.org/dc/terms/
dbohttp://dbpedia.org/ontology/
foafhttp://xmlns.com/foaf/0.1/
dbpedia-huhttp://hu.dbpedia.org/resource/
prop-huhttp://hu.dbpedia.org/property/
rdfshttp://www.w3.org/2000/01/rdf-schema#
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
n9http://hu.dbpedia.org/resource/Sablon:
provhttp://www.w3.org/ns/prov#
xsdhhttp://www.w3.org/2001/XMLSchema#
n8http://hu.dbpedia.org/resource/Kategória:

Statements

Subject Item
dbpedia-hu:GoF_1_alapelv
rdfs:label
GoF 1 alapelv
dct:subject
n8:Programozási_paradigmák n8:Programtervezési_minták
dbo:wikiPageID
1712277
dbo:wikiPageRevisionID
23721694
prop-hu:wikiPageUsesTemplate
n9:Cite_book n9:Nincs_bevezető
prop-hu:author
Gamma, Helm, Johnson & Vlissides Kollár Lajos, Sterbinszky Nóra Dr. Kusper Gábor
prop-hu:isbn
0
prop-hu:publisher
Addison-Wesley
prop-hu:ref
Gang of Four
prop-hu:title
Design Patterns Programozási technológiák
prop-hu:year
2014 2015 1994
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.
prov:wasDerivedFrom
wikipedia-hu:GoF_1_alapelv?oldid=23721694&ns=0
dbo:wikiPageLength
5739
foaf:isPrimaryTopicOf
wikipedia-hu:GoF_1_alapelv
Subject Item
wikipedia-hu:GoF_1_alapelv
foaf:primaryTopic
dbpedia-hu:GoF_1_alapelv