„Tervezési minták (Sznikák)” változatai közötti eltérés

== Singleton ==

'''Célja:''' Biztosítja, hogy egy osztályból csak egy példányt lehessen létrehozni, és ehhez az egy példányhoz globális hozzáférést biztosít.

'''Megoldás:'''

* Legyen az osztály felelőssége, hogy csak egy példányt lehessen belőle létrehozni

** globális hozzáférés a példányhoz

A Singleton konstruktora protected láthatóságú! Ez garantálja, hogy csak a statikus Instance metódushíváson keresztül lehessen példányt létrehozni.

'''Kód (C#):'''  

public class Singleton{

Igazi, publikus, mély másolatot végző klónozáshoz implementálható az ICloneable interfész:

* Object Clone() művelet (deep copy)

'''Előnyök'''

* objektumok hozzáadása és elvétele futási időben

* új, változó struktúrájú objektumok létrehozása

* redukált származtatás, kevesebb alosztály

'''Hátrányok'''

* Minden egyes prototípusnak implementálnia kell a Clone() függvényt, ami igen bonyolult lehet

== Adapter ==

'''Cél:''' Egy osztály interfészét olyan interfésszé konvertálja, amit a kliens vár. Lehetővé teszi olyan osztályok együttműködését, melyek egyébként az inkompatibilis interfészeik miatt nem tudnának együttműködni.

'''Példa:''' Grafikus editor

Objektum kompozícióval, delegálással oldja meg az adaptálást

'''Szereplők: '''

* mint a Class Adapter-nél

* az adapter delegálja a művelet végrehajtását az Adaptee-ra

* agy adapter képes több Adaptee-t is magában foglalni, beleértve azok alosztályait is

'''Használjuk, ha '''

* egy olyan osztályt szeretnénk használni, amelynek interfésze nem megfelelő Adapter

== Decorator ==

'''Célja:''' Objektumok funkciójának dinamikus kiterjesztése. Rugalmas alternatívája a leszármaztatásnak.

'''Példa:''' Adott egy GUI keretrendszer (pl. Windows Forms-Decorator Formshoz, AWT-hez hasonló). Az ablakokokhoz, vezérlőelemekhez hozzá szeretnénk rendelni keretet (Border), görgetősávot (Scrollbar), Animációt (Animation), Árnyékot,... Ezeket tetszőleges kombinációban szeretnénk az osztályokhoz rendelni. Tegyük fel hogy beépítve NEM támogatja a keretrendszer!

'''Használjuk, ha '''

* dinamikusan szeretnénk funkcionalitást/viselkedést hozzárendelni az egyes objektumokhoz

* a funkcionalitást a kliens számára átlátszó módon szeretnénk az objektumhoz rendelni

* amikor a származtatás nem praktikus

'''Előnyök '''

* sokkal rugalmasabb, mint a statikus öröklődés

* több testreszabható osztály határozza meg a tulajdonságokat

'''Hátrányok '''

* némiképp bonyolultabb, mint az egyszerű öröklés (több osztály szerepel)

== Facade ==

'''Célja:''' Egységes interfészt definiál egy alrendszer interfészeinek halmazához. Magasabb szintű interfészt definiál, amin keresztül könnyebb az alrendszer használata.

'''Példa:''' Compiler; Többrétegű (többnyire üzleti) alkalmazások

'''Használjuk, ha '''

* egyszerű interfészt szeretnénk biztosítani egy komplex rendszer felé

* számos függőség van a kliens és az alrendszerek osztályai között. Ilyenkor ha létrehozva egy Facade-ot elősegítve az alrendszer függetlenségét és a hordozhatóságot

* Layers (rétegelés) esetén

'''Megjegyzés '''

* külön döntés, hogy engedünk-e hozzáférést az alrendszerek osztályaihoz

== Proxy ==

'''Célja:''' Objektum helyett egy helyettesítő objektumot használ, ami szabályozza az objektumhoz való hozzáférést

'''Példa:''' Szövegszerkesztő (sok nagy méretű kép megjelenítésével)

'''Struktúra'''  

* Subject: közös interfészt biztosít a Subject és a Proxy számára (ezáltal tud a minta működni)

* Realsubject: a valódi objektum, amit a proxy elrejt

* Proxy: helyettesítő objektum. Tartalmaz egy referenciát a tényleges objektumra, hogy el tudja azt érni. Szabályozza a hozzáférést a tényleges objektumhoz, feladata lehet a tényleges objektum létrehozása és törlése is.

'''Típusok '''

* Távoli Proxy: Távoli objektumok lokális megjelenítése átlátszó módon. A kliens nem is érzékeli, hogy a tényleges objektum egy másik címtartományban, vagy egy másik gépen van

== Template method ==

'''Cél:''' Egy műveleten belül algoritmus vázat definiál, és ennek néhány lépésének implementálását a leszármazott osztályra bízza.

'''Példa:''' Framework-ben dokumentum megnyitása

'''Előny '''

* lehetővé teszi, hogy az algoritmus invariáns részeit egy helyen definiáljuk, és a változó részeket a leszármazott osztályban adjuk meg. Így megoldható a kódduplikálás elkerülése: a hierarchiában a közös kódrészeket a szülő osztályban egy helyen adjuk meg (template method), ami a különböző viselkedést megvalósító egyéb műveleteket hívja meg. Ezeket a "különböző viselkedést megvalósító egyéb műveleteket" a leszármazott osztályban felül kell/lehet definiálni.

'''Cél:''' Egy kérés objektumként való egységbezárása. Ez lehetővé teszi a kliens különböző kérésekkel való felparaméterezését, a kérések sorba állítását, naplózását és visszavonását (undo)

Nagyon rendszerfüggő (C++, .NET, stb.) a koncepció és az implementáció is

'''Példa:''' felhasználói parancsok

'''Használjuk, ha '''

* a strukturált programban callback függvényt használnánk, OO programban használjunk commandot helyette.

* szeretnénk a kéréseket különböző időben kiszolgálni. Ilyenkor várakozási sort használunk, a command-ban tároljuk a paramétereket, majd akár különböző folyamatokból/szálakból is feldolgozhatjuk őket.

* visszavonás támogatására – eltároljuk az előző állapotot a command-ban

'''Előny '''

* elválasztja a parancsot kiadó objektumot attól, amelyik tudja, hogyan kell lekezelni

== Memento ==

'''Cél:''' Az egységbezárás megsértése nélkül a külvilág számára elérhetővé tenni az objektum belső állapotát. Így az objektum állapota később visszaállítható.

'''Példa: '''Visszavonás (undo) funkció a Dokumentumban

'''Struktúra '''

* Originator: az állapotát kell tudni visszaállítani.

* Memento: az Originator állapotát tárolja és elméletileg csak az Originator számára biztosít hozzáférést az állapothoz (state). Pl. C++-ban a friend alkalmazásával oldható ez meg.

* CareTaker: nyilvántartja a Mementokat

'''Használjuk, ha '''

* egy objektum (rész)állapotát később vissza kell állítani és egy közvetlen interfész az objektum állapotához használná az implementációs részleteket, vagyis megsértené az objektum egységbezárását

'''Előnyök '''

* megőrzi az egységbezárás határait

* egyszerűsíti az Originatort

'''Hátrányok '''

* Memento használata sokszor erőforrásigényes

== Observer ==

'''Cél:''' Hogyan tudják objektumok értesíteni egymást állapotuk megváltozásáról anélkül, hogy függőség lenne a konkrét osztályaiktól

'''Példa:''' MVC vagy Document-View architektúra - A felhasználó megváltoztatja az egyik nézeten az adatokat, hogyan frissítsük a többit?

'''Előnyök'''

* a modell kódjában csak egy IView lista van, így a modell független az egyes IView-t implementáló osztályoktól. A modell újrafelhasználható!

* a rendszer könnyen kiterjeszthető új view osztályokkal. Sem a modellt, sem a többi view osztályt nem kell ehhez módosítani.

* Lehetővé teszi, hogy egy objektum megváltozása esetén értesíteni tudjon tetszőleges más objektumokat anélkül, hogy bármit is tudna róluk. Ez az ún. observer minta lényege

'''Struktúra: '''

* Subject: Tárolja a beregisztrált Observer-eket; Interfészt definiál Observer-ek be- és kiregisztrálására valamint értesítésére

* ConcreteSubject: Az observer-ek számára érdekes állapotot tárol; Értesíti a beregisztrált observer-eket, amikor az állapota megváltozik

* ConcreteObserver: Referenciát tárol a megfigyelt ConcreteSubject objektumra; Olyan állapotot tárol, amit a megfigyelt ConcreteSubject állapotával konzisztensen kell tartani; Implemetálja az Observer interfészét (Update művelet), ez az, amit a Subject meghív, amikor a ConcreteSubject állapota megváltozik. Ebben frissíti a saját állapotát a megfigyelt ConcreteSubject? állapotának megfelelően

'''Használjuk, ha: '''

* egy objektum megváltoztatása maga után vonja más objektumok megváltoztatását, és nem tudjuk, hogy hány objektumról van szó

* egy objektumnak értesítenie kell más objektumokat az értesítendő objektum szerkezetére vonatkozó feltételezések nélkül

'''Megjegyzés:''' az Observer az egyik leggyakrabban használt minta

'''Előnyök '''

* laza kapcsolat a Subject és az Observer között

* üzenetszórás támogatása

'''Hátrányok'''

* felesleges Update-ek

== Iterator ==

'''Cél:''' Szekvenciális hozzáférést biztosít egy összetett (pl. lista) objektum elemeihez anélkül, hogy annak belső reprezentációját felfedné

'''Példa:''' Lista

'''Használjuk, ha '''

* úgy szeretnénk hozzáférni egy objektum tartalmazott objektumaihoz, hogy nem akarjuk felfedni a bels� m�ködését

== State ==

'''Cél:''' Lehetővé teszi egy objektum viselkedésének megváltozását, amikor megváltozik az állapota.

'''Példa:''' TCPConnection osztály egy hálózati kapcsolatot reprezentál; Három állapota lehet: Listening, Established, Closed; A kéréseket az állapotától függően kezeli

'''Használjuk ha'''

* az objektum viselkedése függ az állapotától, és a viselkedését az aktuális állapotnak megfelel�en futás közben meg kell változtatnia

* a műveleteknek nagy feltételes ágai vannak, melyek az objektum állapotától függenek

'''Előnyök'''

* egységbezárja az állapotfüggő viselkedést, így könnyű új állapotok bevezetése

* áttekinthetőbb kód (nincs nagy switch-case szerkezet)

* a State objektumokat meg lehet osztani

'''Hátrányok '''

* nő az osztályok száma (csak indokolt esetben használjuk)

== Mediator ==

'''Cél:''' Olyan objektumot definiál, ami egységbe zárja, hogy objektumok egy csoportja hogyan éri el egymást (hogyan kommunikál egymással). Megoldja, hogy az egymással kommunikáló objektumoknak ne kelljen egymásra hivatkozást tárolniuk, ezáltal biztosítja az objektumok laza csatolását.  

'''Példa:''' Egy Form vagy dialógus ablak  

'''Szerkezet: '''

Minden vezérlőelem tartalmaz egy referenciát a dialógus ablakra (mediátor)

== Strategy ==

'''Cél:''' Algoritmusok egy csoportján belül az egyes algoritmusok egységbe zárása és egymással kicserélhetővé tétele. A kliens szemszögéből az általa használt algoritmusok szabadon kicserélhetőek.  

'''Példa:''' A kliens objektum különféle sorrendező algoritmusokat használhat; A kliens tartalmaz egy SortAlgorithm típusú pointert/referenciát egy konkrét (QuickSort v. HeapSort) objektumra.