neděle 2. srpna 2009

Knihovny tříd vs. Knihovny komponent

Jako základní stavební kámen vývoje považuji volně provázané komponenty. Problém je v tom, že Java nemá adekvátní prostředky na to, abych mohl vůbec komponentově vyvíjet. Jako největší bolest vidím to, že nemůžeme dosáhnout zapouzdření. To vede k tomu, že v Jave nepoužíváme knihovny komponent, ale knihovny tříd. Knihovny tříd mají tu nevýhodu, že nejsou jasné hranice toho, co je ještě veřejné API a to co je implementační detail. výsledkem je Babylonské zmatení jazyků na úrovni tříd.

Komponenta je něco co má následující charakteristiku.

  • Vícenásobné použití
  • Není specifická pro daný kontext resp. využitelná v různých kontextech
  • Lze jí skládat dohromady s jinými komponentami
  • p
  • Dodržuje zapouzdření pomocí rozhraní
  • Jednotka nezávislého nasazení a verze

Dlouhou dobu jsem si myslel, že OSGi bude tou správnou cestou, ale musím říci bohužel není, alespoň ne v tento čas. OSGi sráží do kolen právě ono stigma toho, že jsme byli celou tu dobu zvyklí vyrábět knihovny tříd. Pokud dnes budete chtit udělat aplikaci postavenou na OSGi, pak narazíte na to, že knihovny třetích stran nejsou vůbec připraveny. A to už nemluvím o tom, že udělat webovou aplikaci nasaditelnou jako přenositelný WAR archív, je věc více než složitá

Paradoxně nejblíže k této charakteristice mají Enteprise Java Beanu, bohužel jejich užití sráží další nevýhody jako například příliš restriktivní programový model. Jsem ohromě zvědavý co vypadne z JSR 277 Java Module Systém. Bohužel si myslím, že alespoň ze začátku tu bude stejný problém jako s OSGi, tedy že na to nebudou knihovny stavěné, nicméně alespoň zacelí mezeru po chybějícím standardu.

Jako další, a nemalý problém, vidím to, že pokud mám technologii jako OSGi, tak je to jenom jedna polovina skládačky. Tou druhou je pro mě kooperace s Dependency Injection frameworkem, který by měl řídit to, jakým způsobem bude vnitřně komponenta assemblovaná. Ideální představa je taková, že komponenta má dané rozhraní představované například Java Interfacem. Implementace je složení několika java tříd pomocí Dependency Injection s tím, že tyto třídy nejsou vidět mimo rozsah komponenty, to znamená, že nikdo nemůže udělat lookup těchto tříd. To je například věc, která je prakticky i ve Springu velice těžko realizovatelná.

Můžu říci, že mě tato chybějící podpora čistého komponentového vývoje nejvíce omezuje v týmovém pojetí. Není například vůbec jednoduché nalinkovat jasné rozdělení odpovědností. Můžu sice o nějakém JARu říci, to je komponenta XYZ, ale ve chvíli, kdy si ho někdo přidá na classpath, tak jakékoliv hranice komponenty padají a použití je řízené tím co nabídne code completion v IDE. Díky tomu se potom jednotlivé JARy používají jinak, než bylo zamýšleno, protože jakékoliv hranice padají.

Java má před sebou dlouhou cestu hledání optimálního řešení, o tom, že je to potřeba není myslím sebemenšího sporu.