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
• 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.