vineri, decembrie 07, 2007

Crearea unei librarii spre reutilizare aka expunerea unui API

Continut
  • un aspect important ar fi crearea de module distincte (Java jars, Osgi bundles) pentru partea publicata/publica (numita in continuare API) si partea de implementare/privata - Maven ca unealta de build incurajeaza o astfel de abordare (exemple:My Faces, si in general toate implementarile dupa API specifications - partea publica vine din specificatie; alte exemple SPI - interfete expuse spre implementare in JSE/JEE: driverele de JDBC, JNDI; connectorii JMS, JMX)
  • API-ul contine doar servicii - fara stare; DTO-uri - doar stare - pentru transport; exceptii - exceptii de business aruncate de API; enum-uri - colectii de constante (se va evita folosirea interfetelor pentru a defini constante)
  • impartirea librariei in mai multe module pe criterii tehnologice sau de business - utilizatorul poate sa creeze o dependenta numai de unele dintre ele - nu trebuie sa inghita tot (exemple de astfel de librarii: Compass, Spring)
  • dependentele intre pachete/module trebuie sa fie sub forma uneui DAG fara deepndente circulare - posibilitatea de a lucra in izolare pe pachete/librarii diferite releasate independent si cat mai des (evitarea share-ului in SCM a aplicatiei ca un intreg prin folosirea de proxy-uri de artifate - Artifactory)
  • cantainerele OSGi ofera un nivel avansat de incapsulare, permitand gestiunea dependentelor la o granularitate mai mica: la nivel de pachet
  • folosirea judicioasa a modificatorilor de acces (ex: field-uri private accesate prin mutators publici)
  • unitatea de relese este pachetul/modulul - pastrarea compatibilitatii inapoi intre versiunile majore (exemplu Spring)
  • un sistem clar de versionare a binarelor - regulile de la Apache sunt suficiente
  • reutilizare de cod reprezinta posibilitatea de a refolosi o librarie deja compilata (in compile time si runtime pentru client)

Integrare

  • distinctie intre partea publica si cea publicata (articol Martin Fowler)
  • dependente doar cu partea publicata dintr-o librarie straina utilizata in compile time si runtime (nici o dependenta de implemntare)
  • ascunderea sub key-uri a implementarilor (JNDI furnizat de serverul de aplicatii/registru de nume/Service Locator, IOC/fiseiere de configurare Spring/DI)
  • ascunderea implementarilor prin interfete din API-ul expus
  • injetarea de implementari in runtime (DI - implicit de catre container in boot time - Spring, Service Locator - explicit de catre client in runtime - EJB 3)
  • dependente injectate dinamic - serviciile OSGi - prin redepoyere si restartare de bundle-uri in containerul OSGi
  • partea publica va fi alcatuita dintr-un set de servicii expuse explicit prin care se da acces la businessul modelat de librarie - Services Facade Pattern
  • comunicarea se realizeaza prin Java Bean-uri DTO fara logica (functionalitate) - doar stare
  • clientul va folosi partea publicata a altei librarii doar printr-o zona de cod a sa Gateway Pattern fara a murdari restul
  • dependentele trebuie gestionate cu atentie (la nivel de module - Maven / la nivel de pachete si module OSGi)