tag: injection

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 »

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ó: