Ígéretemhez híven folytatom tervezési mintákat bemutató cikksorozatomat.
Az egyik legalapvetőbb és valószínűleg leggyakrabban használt minta az egyke minta. A neve is mutatja legfőbb jellemvonását: az adott osztályból egyetlen példány jön létre az alkalmazás futása során.
Erre akkor van szükség, ha az adott objektumból felesleges, sőt zavaró lenne több példányt létrehozni; jó példa erre a hibanaplózó vagy teszem azt az XML-feldolgozó osztály.
A cél tehát egy olyan módszer bevezetése, amely garantálja, hogy mindössze egy objektumot lehet létrehozni az osztályból.
Az első, szembeötlő nehézség az, hogy az osztály konstruktorát bárki meg tudja hívni - ezt kell megakadályozzuk.
A megoldás a konstruktor elrejtése - tegyük priváttá, és ezzel megakadályozzuk a közvetlen példányosítást. Azonban valahogy biztosítanunk kell az osztály példányosítását, hiszen különben mindössze egy használhatatlan osztályt kaptunk.
Ezt a célt szolgálja az Instance() tagfüggvény, amely az egyetlen osztálypéldány létrehozásáért felelős.
Az osztály egyetlen példánya az első Instance() hívás során jön létre, az ezt követő hívások pedig ezt a példányt adják vissza.
 Egy Singleton osztály (avagy Egyke) létrehozásának menete:
- rejtsük el a ctor-okat, a másoló ctor-t és az "operator =" -t (ezáltal lehetetlenné tesszük a közvetlen példányosítást)
- deklaráljuk az adattaghoz történő hozzáférését biztosító, static public metódust (általában Instance() névre hallagat)
- deklaráljuk az osztály példánymutatóját statikus privát adattagként (ez az adott osztályra egyetlen példányának címe)
- gondoskodjunk arról, hogy az első hozzáféréskor létrehozzuk az egyetlen osztálypéldányt, minden azt követő híváskor pedig a már létező objektumpoinetrt adjuk vissza
Bővebben...
|
 A szoftvertervezési minták négy közismert úttörője Erich Gamma, Richard Helm, Ralph Johnson és John Vlissides ( bővebben itt olvashatunk róluk:http://hillside.net/patterns/DPBook/GOF.html)
Tudtommal az első könyvet nekik köszönhetjük a témában, bár valószínűleg nem ők találták fel a spanyolviaszt. Számos fejlesztő szembesült már ugyanazzal a problémával, illetve feladattal, és valószínűleg sokan azonos, vagy csak apró részleteiben eltérő megoldásokra jutottak. Ezeket nevezzük mintának, ugyanis egy ismétlődő, jellemző problémakörre jelentenek szabványos megoldást.
A mintákat tehát a könyv megjelenése előtt is használták a fejlesztők, viszont senki sem foglalta össze - legfeljebb céges dokumentáció formájában keringett egy zárt közösségen belül.
Az említett négy úriember azonban vette a fáradtságot, és írt egy könyvet: egy klasszikus, mondhatni alapmű, amely nem hiányozhat egyetlen - magára valamit is adó -, programozó könyvtárából sem.
A "Tervezési minták" (Design Patterns) című könyvről van szó, amely három nagy csoportba szervezi a programtervezési tervmintákat:
Bővebben...
A következőkben a szoftverfejlesztésben alkalmazott alap-mintákat tárgyaljuk.
A cikkben taglalt fogalmak az objektum-orientált világ alapkövei, amelyek nélkül nem lehet megvalósítani az összetettebb mintákat. Öröklődés, asszociáció, aggregáció, kompozíció
Az osztályok közötti kód-újrafelhasználás módozatai (szülő-gyermek kapcsolat vagy hivatkozás, tartalmazás). Az általánosítás a hasonló tulajdonságokkal rendelkező osztályok közötti kapcsolatot írja le. 
Az asszociáció az osztályok közötti függőséget fejezi ki. A képen egy irányítatlan asszociáció látható, amelynél mindkét osztály 'tud' a másikról. Az irányított asszociáció esetében csak az egyik fél ismeri a másik osztályt, amit nyíllal jelölünk. 
Bővebben...
ArchitectureMíg az alkalmazáskód ellenőrzésére számos módszert alkalmaznak (statikus kódellenőrzés, automatizált tesztelés, stressz-teszt stb.), addig a rendszer tervét viszonylag ritkán veszik górcső alá. Az esetek többségében a szabványos ellenőrzési módszertan hiánya jelent akut gondot. Így előfordulhat, hogy a tervezésből fakadó hiányosságok csak a fejlesztés előrehaladtával derülnek ki. Ennek pedig komoly ára van, hiszen rossz esetben akár az alkalmazás teljes áttervezését is eredményezheti. A lehető legrosszabb eset pedig az, amikor a rossz design alapján folytatódik és fejeződik be a project.
Bővebben...
 A cikk a két legsűrűbben alkalmazott geometriai primitívvel - TRIANGLELIST és TRIANGLESTRIP - foglalkozik, mindezt az optimalizálás szempontjából vizsgálva.
Kitérek az index puffere is, és a TRIANGLESTRIP / indexpuffer látszólag ellentmondásos viszonyára. A cikkben idézek a nemrég megjelent Shaderprogramozás című könyvemből, ahonnan néhány ábrát is kölcsönvettem a jobb érthetőség kedvéért.
A TRIANGLELIST (különálló háromszögek sorozata) a legalapvetőbb geometriai primitív, amelyből felépíthetjük a geometriánkat.
Előnye, hogy átlátható, hiszen minden háromszög csúcspontja jól beazonosítható, ezért egyszerű testeket akár közvetlenül a kódból is megadhatunk általa: Nyilvánvaló hátránya az, hogy a csúcspontadatok a vertexpufferben ismétlődő, redundáns módon szerepelnek.
Bővebben...
|
|
|
|
|
|
JPAGE_CURRENT_OF_TOTAL |
Programozás
