pátek 21. května 2004

Editorial a články na víkend

Ufff, po dvou dnech od klávesnice s rukama otlučenýma od zednického kladiva, kytary(rozuměj lopaty), vápna, cementu a dalších zednických ingrediencí jsem se vrátil do oázy klidu mého pracoviště. Bohužel návštěva za pracovním stolem má charakter pouze společenský, zkontrolovat(promazat) poštu, okouknout bugy neboť finišujeme verzi a načerpat fyzické i psychické síly. Od pondělí do čtvrtka mě čeká další kolo omítky rodinného domu a síla na blogování mi asi stačit nebude.

Články na víkend

Během mojí nepřítomnosti se v týdnu vylouplo několik zajímavých článků, například neoficiální vyjádření ministra Vladimíra Mlynáře k otázce softwarových patentů.

pondělí 17. května 2004

J2EE vzory: Inversion of Control a Dependency Injection

Na J2EE vzory Inversion of Control a Dependency Injection jsem narazil v souvislosti s J2EE frameworkem či lightweight kontejnerem Spring. Oba vzory popisují propojení aplikačních komponent a jsou jádrem právě kontejnerů jako zmiňovaný Spring, PicoContainer nebo Avalon.

Inversion of Control

Vzor Inversion of Control zkráceně IoC řeší těsné vazby mezi aplikačními komponentami, které jsou pevně provázány v aplikačním kódu. Řekněme, že máme komponentu Acme, který využívá komponenty Foo a Hoo. Ve většine případů je vazba řešena přímo kódem, ve kterém Acme instancuje komponenty Foo a Hoo.

 
    class Acme ....
	private Acme(){
          foo = new Foo();
          hoo = new Hoo(); 
	}
 

Nevýhoda tohoto kódu je v tom, že Acme je těsně svázáno s Foo a Hoo. Zvažme příklad, kdy budeme mít komponentu FooBar, kterou budeme chtít použít místo Foo(Foo i FooBar implementují stejné rozhraní). Budeme muset změnit kód a místo Foo instancovat FooBar, díky této provázanosti budou všechny změny závislé na úpravě kódu a jeho zkompilování.

Tyto problémy řeší právě IoC(obrácená kontrola), kde jsou komponenty provázány z vnějšku. Komponenta Acme(spotřebitel) nevytváří instance Foo a Hoo, ale instance těchto komponent se jí nastaví z vnějšku.

 
    class Acme ....
	public void setFoo(FooInterface foo)..
        public void setHoo(HooInterface hoo).. 
 

Nyní na řadu přicházejí ony zmíněné lightweight kontejnery, které ono nastavení z vnějšku realizují. Provázanost tedy volba konkrétní instance se děje pomocí konfigurace, která bývá nejčastěji v XML. Kontejner pak podle konfigurace řídí vlastní vytváření komponent a jejich nastavení. Obrácená kontrola umožňuje vznik objektů na výše postavených vrstvách a jejich doručení přímo k jejich spotřebiteli.

Dependency Injection

Dependency Injection jde ruku v ruce s IoC a řeší nastavení či doručení komponent k jejich spotřebiteli. Existují tři základní způsoby nastavení

Setter injection
Injekce se děje pomocí klasických setteru čili setovacích metod známých například z modelu JavaBean. Tento způsob používá framework Spring.
Constructor injection
Injekce se děje přes konstruktor a používá ji framework PicoContainer.
Interface injection
Injekce přes rozhraní je realizována přes definici rozhraní, kterým se provádí nastavení komponenty a typickým představitelem je framework Avalon.

Velká diskuse se točí kolem toho jaký způsob zvolit. Injekce skrz rozhraní stojí trošku na okraji a tak se především diskutuje jestli je lepší použít settry nebo konstruktor. Obě mají své výhody a nevýhody a nerad bych se pouštěl do jejich srovnání neboť to je na další článek.

Pokud Vás tato problematika zajímá tak mohu vřele doporučit následující zdroje, ze kterých jsem čerpal.