ElePHPantFan

Ez az állítás mind rám mind a blogolási tevékenységemre is igaz.

Egy ideje már németföldön koptatom a billentyüzetet. Rengeteget tanultam ez idö alatt, többek között azt is, hogy a publikálás, blogolás szerves része a szakmai fejlödésnek; a visszatekintés, összefoglalás segít abban, hogy az ember megtalálja a szakmai hiányosságait, illetve jobban rögzül a "tananyag".

Az új blog nyelve angol, mivel erösen multikulturális környezetben tevékenykedem mostanság, így ezzel is gyakorlom a nyelvet. 

Az új blog címe:  http://elephpantfan.blogspot.com

Ezutón is sikerekben gazdag Boldog Új Évet kívánok minden idetévedõnek!

Manapság rengeteg PHP framework érhető el, mindegyik a maga előnyével és hátrányával. Többször nehéz dönteni, hogy egy projekthez mely keretrendszer felhasználása lenne a legjobb megoldás. Az egyik keretrendszernek az MVC része, egy másiknak pedig az ORM implementációja az igazi. A kérdés az, hogy van-e arra mód, hogy egy-egy keretrendszernek csak a számunkra hasznos részét használjuk fel, anélkül, hogy több megabájtnyi "felesleges" forráskódot húznánk be?

A válasz igen. Ennek a problémának az orvoslására van egy roppant egyszerűen felhasználható tool: a Composer.

A Chain of Responsibility egy Behavioral pattern, az objektumok viselkedési módját határozza meg.

Mikor alkalmazzuk: konkrét példával élve - egy adott inputot több szűrőn is végig kell vinni úgy, hogy a szűrőket könnyen ki és be lehessen építeni a szűrőrendszerbe.
 

Most egy másik Creational Pattern kerül bemutatásra: a Factory Method.

Ahogy a neve is utalja - valaminek a legyártására lett kitalálva - OOP világában az objektumok gyártása a cél.

Mikor alkalmazzuk: ha előre nem tudjuk vagy nem is akarjuk kikötni azt, hogy mely osztály példányára lesz szükségünk - azaz növeljük a kód és az üzleti logika közötti függetlenségét.

Az okoskodásaimat a tervezési mintákkal kezdeném (Design Patterns).

Tulajdonképpen a design pattern egyveleg nem más, mint egy újrahasznosítható problémamegoldások halmaza. Az igaz, hogy a kódolásnál fellépő problémák/megoldásra szoruló helyzetek száma közelít a végtelenhez, viszont az is igaz, hogy minden egyes probléma több, kisebb problémára redukálható. Így ezen redukció lévén eljuthatunk egy olyan szintig, amelyre már valaki valamikor írt egy megoldást. Ami ezesetben valamely design pattern.

Részletesebben most nem merülök bele a patternek elemzésébe, csoportosításába, etc. Inkább a gyakorlati alkalmazásukkal foglalkoznék - milyen esetben milyen mintát szükséges alkalmazni.

A Singleton mintával kezdeném.