A gyári módszer egy kreatív tervezési minta, azaz az objektum létrehozásával kapcsolatos. A gyári mintában objektumot hozunk létre anélkül, hogy a kliensnek kitennénk a létrehozási logikát, és az ügyfél ugyanazon közös felületet használja új típusú objektumok létrehozásához.
Az ötlet egy statikus tag-függvény (statikus gyári módszer) használata, amely létrehozza a & példányokat ad vissza, elrejtve az osztály moduljainak részleteit a felhasználó elől.
A gyári minta az objektum létrehozásának egyik alapvető tervezési elve, amely lehetővé teszi az ügyfelek számára objektumok létrehozását egy könyvtár (az alábbiakban kifejtve) oly módon, hogy ne legyen szorosan összekapcsolva a könyvtár osztályhierarchiájával.
Mit jelent, ha könyvtárról és kliensekről beszélünk?
Könyvtár olyan valami, amelyet harmadik fél nyújt, amely néhány nyilvános API-t tesz elérhetővé, és az ügyfelek felhívják ezeket a nyilvános API-kat a feladatuk elvégzése érdekében. Nagyon egyszerű példa lehet az Android OS által biztosított különféle nézetek.
Miért a gyári minta?
Értsük meg egy példával:
Kimenet:
I am two wheeler
Mi a probléma a fenti kialakítással?
Amint azt a fenti példában észrevehette, az ügyfél a TwoWheeler bármelyikét létrehozza vagy a FourWheeler az objektum elkészítése során elért valamilyen bemenet alapján.
Mondjuk, a könyvtár egy új, háromkerekű osztályt vezet be, amely háromkerekű járműveket is tartalmaz. Mi történne? Az ügyfél végül egy új mást láncol, ha a feltételes létrán hozza létre a ThreeWheeler objektumait. Amihez viszont újra kell fordítani az Ügyfelet. Tehát minden egyes alkalommal, amikor új változtatásokat hajtanak végre a könyvtár oldalán, az Ügyfélnek végre kell hajtania néhány megfelelő módosítást a végén, és újra össze kell állítania a kódot. Rosszul hangzik? Ez nagyon rossz tervezési gyakorlat.
Hogyan kerülhető el a probléma?
A válasz az, hogy hozzon létre egy statikus (vagy gyári) módszert. Lássuk az alábbi kódot.
Kimenet:
I am three wheeler
A fenti példában teljesen leválasztottuk az objektum létrehozásának típusát az Ügyfélről. A könyvtár feladata, hogy egy bemenet alapján eldöntse, hogy mely objektumtípust hozza létre. Az ügyfélnek csak felhívnia kell a könyvtár gyárának Create metódusát, és át kell adnia a kívánt típust anélkül, hogy aggódnia kellene az objektumok létrehozásának tényleges megvalósításáért.
Köszönet a Rumplestiltskin-nek a fenti magyarázatért.
A gyári módszer további példái:
- Tegyük fel, hogy egy “Rajz” rendszerben a felhasználó bemenetétől függően különböző képek rajzolhatók, például négyzet, téglalap, kör. Itt gyári módszerrel létrehozhatunk példányokat a felhasználó inputjától függően. Új típusú alakzat hozzáadásához nem kell megváltoztatni az ügyfél kódját.
- Egy másik példa: Az utazási oldalon foglalhatunk vonatjegyet, buszjegyet és repülőjegyet is. Ebben az esetben a felhasználó megadhatja utazási típusát: „busz”, „vonat” vagy „repülés”.
Itt van egy absztrakt „AnyTravel” osztály, statikus tagfunkcióval „GetObject”, amely a felhasználó utazási típusától függően hozza létre a „BusTravel” vagy a „TrainTravel” visszatérő objektum & visszatérési objektumát. A „BusTravel” vagy a „TrainTravel” olyan közös funkciókkal rendelkezik, mint az utas neve, az eredet, a célparaméterek.
Köszönet Abhijit Sahának, aki megadta az első 2 példát.
