category: design-pattern

17Jul

Law of Demeter - Ne állj szóba idegennel!

Az utolsó design cikkhez értünk, ez a SOLID utáni ráadás. Law of Demeter, más néven a principle of least knowledge egy ajánlás  a szoftverfejlesztéshez, azon belül is az objektumorientált nyelvekhez. Ha valaki találkozott már a kódjában hosszú method chainingel, mint például:

$user = $this->getServiceLocator()->get("SqlModelFactory")->createModel("Users")->findById($ID); // félreértés ne essék, nem minden method chaining lesz "rossz"
Szeged-domotor

A szegediek lehet értik

akkor valószínűleg nem árt, ha olvassa ezt :)

Tovább »

16Jul

She wants the DI

A SOLID sorozatunk utolsó része következik, ahol a Dependency Inversion Principle, röviden DIP lesz terítéken. Alkalmazásunk felépítését tekintve többszintű hierarchiát képez. Ha megvizsgáljuk az osztályainkat és azok függőségeit, akkor egy faszerkezetet rajzolnak ki, ahol a fa gyökere felé haladva egyre magasabb és magasabb szintű osztályok következnek. tree-451x320Amikor tervezzük az alkalmazásainkat, a gyakorlat az, hogy először azokkal az alacsonyszintű osztályokkal kezdjük, amik az egyszerű műveleteket végzik, mint a lemezelérés, hálózati protokollok, stb. (Ezek lesznek a levelek) Ezután fogjuk ezek működését egységbe zárni magasabb szintű osztályainkba, ahol a komplex logika található (üzleti folyamatok, stb.). Ahogy a sorrendből is lehet rá következtetni, ez utóbbiak függnek az alacsony szintű osztályoktól. Ebből kifolyólag az előbbi elgondolás, miszerint a low-level osztályoktól a high-levelek felé haladunk a megvalósítás során. A probléma itt a flexibilitás lesz, ugyanis ha az egyik alacsonyszintű osztályt le kell cserélni valahol, akkor meg vagyunk lőve, mert a magasabb szintű osztályainkat ennek implementációjára építettük.

Tovább »

09Jul

ISP - Interface segregation principle

Amikor új applikáció tervezésébe kezdünk, akkor nem árt komolyan fontolóra venni, hogy milyen absztrakciókat is fogunk használni az egyes modulok és submodulok esetén. Ha ezen modulok egyike esetünkben egy osztály, akkor az absztrakció formája nem lesz más, mint egy interface. Tegyük fel, hogy ezt létrehoztuk és az adott osztályt implementáltuk is, minden klappol, megkaptuk érte a kis pénzünket és nem utolsó sorban úgy működik, ahogy a megrendelő elképzelte elképzeltük. refactoring-to-solid-code-32-728

Tovább »

05Jul

Betonozás 3.0 - Liskov és a haverok

Kódolni pofonegyszerű.
Legalábbis a facebook hirdetéseink alapján ma már mindenféle tudás nélkül bármit össze lehet kattintgatni és még lehet külsőre jól is néz ki. Ellenben ha minőségi munkáról van szó, akkor bizony közel sem olyan egyszerű a dolog. Ha húsz év múlva mi, programozók "uraljuk" majd a világot és ha véletlenül okozunk valami gebaszt, ami komoly károkat okoz, akkor biza a sarkunkra lépnek. A gond az, hogy a történelem jelen állása szerint akkor nem tudunk semmit felhozni majd a védelmünkre.
Miért nem?
Ugyanis szinte minden szakmában vannak bizonyos szabályok, amiket betartanak. Szabályozva vannak, normák szerint dolgoznak. Ellenben ha belegondolok, hogy is nézett ki az első pár kódsor, amiért pénzt mertem kérni, nos az egy szabálynak felelt meg:
  • matchelt rá a .* regexp karakterekből állt.
Viszont szükségünk van szabályokra, hogyha egyszer odaáll elénk a főnőkünk, akkor tudjuk azt mondani, hogy én betartottam a szabályokat, minden másra ott a 'not my fault!', a tesztek lefutottak, tehát minden tőlem telhetőt megtettem a minőség érdekében. Ha egyszerre többen dolgoznak egy projekten szintén kellenek a szabályok, mert hiába a compiler, ritka ronda dolgok másznak ki a kezünk alól, ha eluralkodik az irodában a káosz (itt most egy perc néma megemlékezés azokért, akik mind a mai napig verziókövetés nélkül dolgoznak csapatban ). Ezen szabályok egyik gyűjteménye az ún. SOLID irányelvek, aminek a harmadik betűjét fogjuk most megvizsgálni, az LSP-t (Liskov's substition principle) magyarul.. inkább nem írom le. liskov

Tovább »

16May

Az oktrojátor pattern és az IoC container

Az objektumorientált programnyelvekben értelemszerűen objektumokkal dolgozunk. Apróbb programok esetén, mikor nem használunk erre kitalált keretrendszert, az objektumpéldányaink menedzselése ránkmarad. Ahhoz, hogy a kódunk moduláris és tesztelhető legyen, az objektumaink függőségeit be kell "oktrojáljuk" a egymásba. Akinek a dependency injection nem tiszta, annak itt ez a cikk, mert szükség lesz rá a későbbiekben. Ez az egymásba pakolászás egy idő után eléggé komplex lehet, ezért egyes keretrendszerek, így a Laravel vagy Java nyelvben a Spring erre a célra rendelkezik egy ún. IoC containerrel. Ezekről lesz a cikkben szó.145cs1

Tovább »

08May

Repository-k a verziókövetésen is túl

Amikor az ember kódolásba kezd, akkor gyakorta törekszik arra, hogy a kódja egyes részeit újra tudja hasznosítani, hogy azok modulárisak legyenek, át tudjuk vinni őket A projektből B projektbe, anélkül, hogy reflectionnel megerőszakolnánk az egészet fejfájást okoznánk magunknak vagy másoknak és ugyanolyan könnyedén használható maradjon mindez, mint az A projekt esetében. Azonban mi a helyzet, ha pl. különböző adatforrások között szeretnénk váltani?IC340233

Tovább »

28Apr

Díszítsük fel a wrappert!

A decorator pattern a struktúrális minták közé tartozik, és a célja roppant egyszerű: magába foglal egy másik osztályt és plusz funkcionalitással látja el azt, így az eredeti osztály metódusai érintetlenek maradnak. Nézzük meg hogy is történik mindez!  

Forrás: foodnetwork.com

Forrás: foodnetwork.com

Tovább »

13Oct

Martin papa színrelép - Az adataink

Az bizonyára köztudott, hogy manapság már nem weboldalakat, hanem webalkalmazásokat készítünk, azok mérete és komplexitása miatt. Ezzel a mérettel és komplexitással szinte egyenes arányban egyre bonyolultabb és hatalmasabb adatbázisok csücsülnek a háttérben. A módszer, hogy ezeket az adatokat hogy is érjük el, igen sokféle lehet. Régen, amikor még nem figyeltünk a kód struktúrájára, egy mysql függvény figyelt egy lekéréssel az index.php közepén, később már ezeket feldaraboltuk, netán kiszerveztük különféle fájlokba. Amikor viszont szóba jön az MVC, már mindenhol objektumokkal dobálózunk, akkor sokan eltévednek a nagy útvesztőben, hogy mégis mit és hova? pq2vg

Tovább »

03Sep

Strategy pattern, az objektumok lázadása

Minden fejlesztő életében vannak nehéz napok, mikor iOS push notificationt akar megvalósítani C#-al úgy érzi, hogy az általa kreált objektum jónak jó, de mi lenne ha több mindenre lenne jó, anélkül, hogy rommápakolnánk mindenféle plusz metódusokkal? Mi lenne, ha igazából nem is új funkcionalitást akarunk belevinni, csupán a jelenlegi működést akarjuk megváltoztatni, akár futásidőben. Erre és a hasonló kérdésekre kaphatunk választ a pszichológusunknál az alábbi cikkben a strategy pattern által. screen_03

Tovább »

06Jul

Termi(ter)ator 2

A mai téma egy roppant egyszerű tervezési minta lesz, amire - ahogy a későbbiekben kiderül - a 3-31-Leadprogramnyelveink többségében már példát is találunk. Ha valaha volt már dolgod valamilyen adatbázissal (amit erősen remélek), legyen az mongo vagy épp SQL, akkor nagy az esély, hogy tömbökön másztál végig, mikor a lekérések eredményeit jelenítetted meg/végeztél vele műveletet. A végigjárásra a foreach parancsot használtad, amiről nem is sejtenéd, hogy mennyi köze lesz a mai témához.

Tovább »

16Jun

Observer pattern és a Robotics Facility

starcraft_2_observer_by_worthart-d4ibdiy Protoss observer - Ha nem ismerős, akkor annak idején Te is lemaradtál a dolgokról.. Ez a pattern talán segíthet, hogy ne történjen meg újra!

Akit kapott már hátba egy hadseregnyi zergling, az pontosan tudja, hogy jó dolog, ha időben értesülünk a dolgokról körülöttünk. Az objektumokkal sincs ez másként, bizony őket sem érinti pozitívan, ha bezergelik őket lemaradnak a számukra fontos eseményekről. A mostani témánk az observer pattern lesz, ami a viselkedési minták egyike. Nem, nem a kémkedésről szól, a működése leginkább a hírlevelek világához kötődik, de nem kell megijedni, csak a valóságközeli példák miatt hoztam fel. Tegyük fel, hogy szeretnénk hírlevelet értesítőt küldeni a felhasználóinknak, amikor egy adott adatbázis tábla módosul. Az ilyen és hasonló feladatokra találták ki az observer pattern-t, aminek a lényege, hogy az A objektum "feliratkozik" bizonyos eseményekre, ami események bekövetkeztekor értesítve lesz, vagyis meghívunk rajta egy metódust. De lássuk ezt valami csontszáraz példán át:

Tovább »

16Feb

Builder Pattern és a 7 hardveres

Mai cikkemben a Builder Pattern kerül terítékre, hogy egy újabbat leleplezzünk a létrehozási minták közül. Mielőtt azonban beleugranánk abba, hogy mit is csinálunk ezen mintában, előtte valamit át kell beszélnünk, ami az objektumaink interfészével és működésével kapcsolatos.inception-trailer-movie-leonardo-de-caprio1 Vegyünk egy konkrét példát: Van egy controllerosztályunk, legyen pl. AjaxController, amivel az oldalunkra érkező ajax lekéréseinket szeretnénk kezelni.

Tovább »

29Jan

Tervezési minták - Adapter pattern

Kicsit megtörjük most a sort és a létrehozási minták helyett (amik közül a jómunkásember Builder következne) egy másik csoportból fogunk elővenni egyet, mégpedig a struktúrális minták közül, az adapter pattern-t. Ezen mintának a lényege, hogy két inkompatibilis interfész között hidat képez. Minderre egy különálló osztályt fogunk használni, aminek az a feladata, hogy a két független vagy éppen inkompatibilis osztály funkcionalitását kombinálja.1280px-Notebook-Computer-AC-Adapter A fenti kép is jó például szolgálhat. A laptopunk akkumulátorát és a konnektort egy adapter köti össze, ami a két összeférhetetlen "interfészt" fogja működőképessé tenni. Ellenben írjunk egy példát, az mindig segít. Tegyük fel, hogy oldalunk egy külső API-t használ és ez a szolgáltatás lassú/netán nem mindig elérhető, így a tartalmát szeretnénk gyorsítótárazni, na meg az API kulcsunkat se akarjuk mindenáron pörgetni, nehogy túllépjük a limitet. Ezt a gyorsítótárazást először balga módon a fájlrendszerbe tesszük.

Tovább »

2014-2018 © Letscode.hu. Minden jog fenntartva. Build verzió: