Polymorphic Rants

Spesso navigando alla ricerca di una cosa, mi imbatto in tutt’altro che però può risultare molto più utile. E’ il caso di questo articolo che affronta un problema su cui non avevo mai ragionato a fondo, ma che effettivamente è di grande importanza soprattutto se si stanno sviluppando componenti che dovrebbero essere riusabili o estendibili da terzi.

buona lettura.

Creando una custom tag library ho scoperto che il ciclo di vita delle tl è assolutamente diverso da quello che mi aspettavo. L’idea che avevo è che ad ogni apertura/chiusura del tag sulla jsp corrispondesse un’istanza nuova della tl; questo, effettivamente, poteva corrispondere all’istanza di un alto numero di oggetti (pensiamo ad una tag che crea righe di una tabella HTML), ma riponevo grande fiducia nel garbage collector che facesse il suo sporco lavoro ed io potessi fare finta che il problmema non esistesse!!! (aahh..la pigrizia…).

Sviluppando invece un tag custom, ho visto che mi sbagliavo: il tag ha un ciclo di vita molto più lungo, e mantiene le proprie proprietà all’interno di tutta la pagina in cui è usato (in pratica l’istanza è sempre quella !!).
Sfogliando la javadoc ho trovato risposta alla mia domanda con questo diagramma degli stati:

Mi rimane ancora da capire quando esattamente viene invocato il metodo release() che si occupa di rilasciare la tl….ho fatto qualche prova, ma non ho mai visto invocato il metodo; teoricamente al termine dell’elaborazioen della JSP, però mi piacerebbe averne una conferma…

L’obiettivo di dare responsabilità definite agli oggetti e non trattare esclusivamente con POJO era l’argomento del post di febbraio Persistenza e Proxy Pattern, e la lettura di questo articolo, ha rinvigorito la mia intenzione di approfondire l’argomento. Questo pattern cefca di assegnare ad ogni oggetto la capacità di definire la propria logica di persistenza tramite dependency injection. La soluzione è molto interessante: in questo modo posso effettivamente dire ad ogni oggetto di “salvarsi”, operazione che l’oggetto stesso delegherà ad uno specifico manager,senza passare oggetti-datastore da una parte all’altra..Credo che questa soluzione sia effettivamente più OO del DAO, dove ho sempre la sensazione di aver semplicemente riunito per affinità logiche dei metodi dentro a dei contenitori che poi chiamo classi.

public static EBean fullRetrieve(Connection conn, EBean ebean) throws SQLException {
WfConnectB wfConnectB = (WfConnectB)ebean;
return wfConnectB;
}

….I’m totally speechless….

Da circa tre settimane sto usando NetBeans 4.1 come IDE al posto di Eclipse 3.0.2, ed ora mi sento di poter fare alcune valutazioni:

Scendiamo nei particolari:

• gerarchia delle classi: NB non visualizza la gerarchia di una classe, cosa decisamente importante se si sta studiando dei sorgenti non propri per capire le relazioni fra classi.
• plug-in JUnit: il mantra barra rossa/barra verde è impossibile da seguire con NB…non ci sono barre colorate che indicano il successo o meno dei test, bisogna guardarsi cosa viene stampato sullo standard output.
• navigazione fra metodi:la navigazione fra i metodi di una classe in Eclipse è fattibile anche tramite uno shortcut, in NetBeans io non lo ho trovato e devo andare con il mouse sulla tendina. Sembra una stupidata, ma quando si lavora tirato adeguati shortcut sono fondamentali.
• refactoring: qua Eclipse surclassa NB che offre 4 (quattro) mosse di refactoring (e pure meno complete rispetto alle corispondenti di Eclipse); Eclipse ne avrà circa 15.
• autocompletamento metodi: quello di NB è lento su una macchina a 2ghz con 1 giga di RAM (wait..)
• personalizzazione warning: Eclipse indica (se si vuole) gli import non necessari, oggetti istanziati e mai usati, metodi mai chiamati. NB niente di tutto questo!!
• pop-up sorgenti: con Eclipse basta posizionarsi sopra la chiamata ad un metodo tenendo premuto CTRL e vedo in una pop-up il corpo del metodo…ed in NB ?
• integrazione su J2EE : qua NB vince perchè la gestione dei server e del deploy per lo sviluppo è veramente trasparente e veloce; la mia esperienza nell’universo Eclipse è sempre stata con Lomboz che, devo dire, è tutt’altro che perfetto.

altro da aggiungere ?
beh….primo impegno per il futuro: riuscire a far adottare a tutto il team Eclipse al posto di NetBeans!!!