tag: dependency

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 »

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 »

30Dec

Javascript pakk 3 - Kinek kell a JS?

Azt már az előző cikkemben is említettem, hogy bizony frontendesnek lenni nem csak a húszéveseké fenékig tejfel. A böngészők, habár okosak, mindent nem tudnak helyettünk, főleg azért, mert a HTML nem programnyelv, hanem amint a neve is mondja, sima leíró nyelv, ezért habár ezen is mindig csiszolnak picit, a lehetőségek korlátozottak. Az egyik ilyen problémát jelenti például az, hogy rengeteg külső libet használunk, össze-vissza és néha már azt se tudjuk melyik mikor is töltődött be, hiszen itt jön a poén, hogy bizony bele kell kalkulálni azt is, amíg lejön. Szerencsére erre gondoltak, amikor különböző eventeket hajigált a dokumentum, de továbbra se ment meg bennünket attól, hogy olyan dolgokra hivatkozzunk, amik akkor még a böngészőnk JS motorja számára nem ismerős:

Uncaught ReferenceError: jQuery is not defined(…)
Persze más programnyelvekben is ismerős lehet mindez, dobhat kivételt a ClassLoader, jöhet egy Class not found hibaüzenet, és még sorolhatnám. Persze ez utóbbiakat egy autoloader, vagy az artifactba foglalás megoldja, de mi a helyzet a javascript frontján? Ebben nyújt nekünk segítséget a RequireJS céltábla

Tovább »

12Mar

Composer - A PHP fejlesztők kedvenc zeneszerzője

Van egy mondás, miszerint az okos/rutinos programozó nem fogja újra és újra feltalálni a kereket, hiszen az teljesen felesleges időpocséklás lenne, hanem leakaszt egy már meglévő library-t a polcról és azt használja, megkímélve magát a sok vesződségtől (vagy épp ezzel generálva azt, de most nem személyeskedünk, igaz?). ludwig-van-beethoven-a-great-composer1 Ha így járunk el, akkor a program, amit készítünk, függ ettől a leakasztott libtől. Ezt nevezik dependenciának, hogy egy kellően gusztustalan idegen eredetű szóval éljek. Ha netán open-source dolgokba bonyolódunk, akkor ezt a külső libet nem fogjuk projektünkhöz mellékelni, hanem a dokumentáció elejébe beírjuk, hogy bizony az e-mail küldéshez kell a PHPMailer 5.2.x vagy újabb, mert mi azzal összeteszteltük és funktzioniert.

Tovább »

21Jan

OOP's I DI'd it again!, avagy dependency injection praktikák

49734Mielőtt bármibe is belekezdenénk, először is tisztáznunk kell mi is az a dependency injection ( függőség injektálás, magyarul elég morbidul hangzik). Az objektumorientált programozásban az osztályaink egymással közreműködnek és legtöbb osztályunk (nem mind, hiszen az lehetetlen) explicit módon igényli egy másik használatát. Ha használtunk már pl. PDO-t egy osztályunkban, akkor is pont ezt tettük. Anélkül az osztály nélkül a miénk sehogyse működne, függ tőle (depends on). Ha még most sem világos, akkor vegyünk egy konkrét példát.

A programozó, mint osztály

class Programozo {
    public function __construct(KaveAutomata $kaveautomata, Eclipse $ide) {
          $kaveautomata->rugdos()->iszik();
          $ide->ujraInditMertMarBelassult();
    }
}
A fenti példa kicsit unortodoxnak tűnhet, de mindjárt elmagyarázom. A dependency injection egyik legegyszerűbb módja az, hogyha a konstruktoron át, a meghíváskor adjuk át a szükséges osztályok példányait (constructor injection). A programozónak ugye szüksége van egy fejlesztői környezetre, amin dolgozik, valamint esetünkben kávéra, ahhoz hogy működni tudjon. Ha ezek nincsenek meg, akkor bizony nem tudjuk munkára fogni az illetőt. A fenti példában explicit módon kikötöttük, hogy automatás kávét iszunk és Eclipse-t használunk. Ez szép és jó, ellenben a kódunkat (és vele együtt a programozót is) bebetonoztuk a kódunkba. Ugyanis mi van akkor, ha elmegyünk egy másik helyre, ahol kotyogós kávéfőző van, netán PhpStorm vagy épp NetBeans? Nos a mi programozónk ezt nem fogja elfogadni és hibaüzenettel elszáll, mert neki bizony elvei vannak.

Tovább »

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