Dependency Injection patern i IoC container – Recept za lako održiv kod

Ivan Đurđevac

Uživam u razvoju arhitekture web aplikacija i učenju novih tehnologija. Učestvovao sam u razvoju DLS platforme za učennje na daljinu kao i mnogih CMS sistema i web aplikacija. Za razvoj mi je trenutno omiljen FuelPHP frejmvork, ali siguran sam da ću uskoro početi da koristim i Laravel4 od kojeg puno očekujem. Koristim NoSQL sisteme kao što su MongoDB i Redis za razvoj skalabilnih rešenja. Od udruženja PHP Srbija očekujem da okupi veliki broj zaljubljenika u PHP tehnolgiju.

Pročitajte i ovo...

9 Komentara

  1. Aleksandar kaže:

    Odličan text Ivane nisam ni sumljao prelepo naučio sam nešto novo. Evo da dam svoj doprinos ono što me zanima i mozda je tema za novi text mada ja imam jos mnogo pitanja ali ovo za pocetak od iskusnih da cujem jel bi mogao neki text na temu Routinga ili Cachinga moze i mali framework kako bi se objasnio npr autoloader pravilno kako to da se uradi i slično.

    Jako dobri textovi Ivane 😀 samo tako nastavi

  2. Alex kaže:

    Odlično kao i prošli put..
    voleo bih da osvane post koji prikazuje ove principe u praksi –
    95% koda + 5% texta 🙂

  3. Goran Maricic kaže:

    Kvalitetan tekst na temu DI/IoC moram priznati.

    Iako školski primeri služe da bi čitaoca uveli u osnove principa i dali širinu u pogledu korišćenja aktuelnih trendova u arhitekturi softverskih sistema, mišljenja sam da bi bilo korisno da čitaoci vide pravi primer korišćenja DI paterna u praksi.
    Možda kroz neki zajednički open source projekat PHP zajednice koji će imati za cilj demonstraciju savremenih trendova u kodiranju u PHP-u, ne limitirajući se samo na DI/IoC već na sve prisutniji trend korišćenja dizajn paterna i dobre prakse u svakodnevnom radu svih nas.
    Verujem da je ovo veliki izazov. Isto tako sam uveren da bi PHP zajednica znala ovo da ceni a ujedno biste bili i začetnik nečega što bi zasiguirno imalo uticaj kako na iskusne tako i na nove programere.

  4. Aleksandar Ilic kaže:

    Uživanje je čitati ovakav tekst. Zadovoljstvo je još veće kada se i nauči nešto novo.
    Hvala Ivane.

  5. Vrlo poucan clanak! 🙂

    Dodao bih misljenje na temu injektovanje argumenata kroz konstruktor (constructor injection) ili kroz setter metode (setter injection).
    Iako nema generalnog pravila za koji nacin cete se odluciti u vecini slucajeva (gotovo uvek) cete zeleti **constructor injection**. Pitanje koje sebi treba da postavite je „Da li moj servis/objekat (Tractor) moze da funkcionise bez nekih zavisnih objekata (dependencies)?“. Ukoliko moze onda slobodno mozete obezbediti interfejs za injektovanje putem setter metoda. U vecini slucajeva vasa klasa nece moci da funkcionise potpuno bez nekih dependencies pa cete se odluciti za constructor injection 🙂
    Nemojte se zaprepastiti ukoliko lista parametara vaseg konstruktora postane previse dugacka, posebno ako morate obezbediti argumente za konstruktor nadklase (ukoliko se radi o nasledjivanju).

    Pozdrav 😉

  6. Žarko,

    Ako bilo koja metoda ima dugačku listu parametara, često je znak lošeg dizajna. U praksi će se desiti da neki od tih parametara u stvari mogu biti sastavni deo nekog novog objekta koji će ih enkapsulirati. Na taj način smanjićemo broj argumenata u metodi.

  7. Ivan Lackovic kaže:

    Svaka cast za text!

    Slazem se sa poslednjim komentarom da ukoliko konstruktor ima mnogo argumenata najcesce klasa ima previse funkcionalnosti cime se krsi Single Responsibility Principle (jedna klasa ima odgovornost tacno jednog dela funkcionalnosti aplikacije), i verovatno kod klase treba da se refaktorise i da se funkcionalnost podeli na vise manjih klasa.

Ostavite odgovor

Vaša adresa e-pošte neće biti objavljena. Neophodna polja su označena *