Keep In Tech Syntax Highlighter plugin for WordPress

Hi, I made a very simple WordPress Plugin to integrate the javascript library Syntax Highlighter from Alex Gorbatchev into your post. Just download the zip file and extract it in your WordPress plugin folder. Then go into the WordPress administration section and activate the KIT Syntax Highlighter plugin.

Usage is very simple. Enclose your code between:

See the site of Syntax Highlighter for more options and languages.

I also use Code Markup plugin for solving wordpress problem with double quotes.

Good Coding!

Un logger come si deve…

Stavolta non vi propongo nulla di nuovo se non un reportage delle scoperte che faccio cercando di imparare ad essere un buon programmatore Java.

Tra i vari dogmi da rispettare c’è, ad esempio quello di utilizzare un framework di Logging per segnalare costantemente l’utente con informazioni di stato sull’applicazione, errori e qualsiasi cosa pensiamo possa essere utile in fase di debugging. Per Java esistono molti framework per effettuare il logging in modo facile ed ho sempre pensato “quando Java incorporerà un framework di logging sarò saziato” ma poi questo è successo ed era lo stesso (op. cit.). Per quanto semplice, chissà per quale motivo, il logging di Java istigava in me la voglia di non utilizzarlo affatto.

Riprendo (e in parte traduco) un post letto su JavaSpecialist.

Per utilizzare un Logger in una nostra classe, dobbiamo dotarla per l’appunto di un Logger:

package com.cretesoft.tjsn;
import java.util.logging.Logger;
public class Application {
  private final static Logger logger =
      Logger.getLogger(Application.class.getName());
  public static void main(String[] args) {
    Application m = new Application();
    m.run();
  }
  public void run() {
    logger.info("Hello");
  }
}

La cosa che non mi scende giù di questo metodo è il fatto che ogni classe che scriviamo deve contenere questo Logger. Inoltre la riga di codice che lo dichiara non può essere semplicemente copiata ed incollata perché dovremmo, quantomeno, cambiare il nome della classe (oggi sono davvero troppo pigro). Inoltre non possiamo sostituire il nome della classe con “this.getClass()” perché perderemmo il vantaggio di avere un Logger statico che non viene istanziato per ogni istanza della classe.

Ed ecco perché io ero così restio ad usare i Logger. Ma ora qualcosa è cambiato 😀

Il trucco sta nel ricorrere al (per me ancora incompreso) pattern Factory per creare un Logger. Per ottenere il nome della classe è possibile ricorrere ad uno stratagemma che consente di ricavarlo attraverso l’analisi dello stack trace:

package com.cretesoft.tjsn;
import java.util.logging.Logger;
public class LoggerFactory {
  public static Logger make() {
    Throwable t = new Throwable();
    StackTraceElement directCaller = t.getStackTrace()[1];
    return Logger.getLogger(directCaller.getClassName());
  }
}

A questo punto possiamo dotarci della riga da copiare ed incollare tra le nostre classi:

private final static Logger logger = LoggerFactory.make();

Volete mettere?

Zac

MonoDevelop 1.0 è uscito

Diamo il benvenuto ad un altro possibile protagonista della scena Open Source ed ovvero MonoDevelop, l’ambiente di sviluppo targato Novell sviluppato da una comunità di sviluppatori di cui ho spesso ammirato la creatività ed altre volte criticato la loro strana tendenza a difendere le posizioni di Microsoft. Com’è come non è adesso MonoDevelop ha raggiunto il suo primo stadio ed è anch’esso un prodotto open source da cui tutti potremo imparare qualcosa (anche quelli che non vogliono exe nella propria Linux Box).

Il progetto, capitanato da Miguel de Icaza, si è distinto negli anni per aver proposto in ambiente Linux (e in tempi recenti anche Windows e Mac OS X) metodologie e strumenti di sviluppo propri dell’ambiente Windows; quanto questo sia in grado di spostare i pigri sviluppatori .Net a Mono, se non addirittura a Linux, e qualcosa che spero di avere il piacere di osservare.

Inoltre auguro al progetto di diventare a breve uno strumento di sviluppo all’altezza di mostri sacri quali NetBeans, Eclipse o IntelliJ IDEA (scusate ma conosco solo questi). Per ora è un prodotto calibrato su C# con un supporto iniziale ad altri linguaggi come Visual Basic.Net, C++, Java e Boo.

Complimenti a tutta la comunità di Mono. Anche se non siete ben visti da molti pinguini “della curva” è ammirevole l’impegno (interessato?) che ci mettete nelle cose che fate.

In bocca al lupo

Sandro Zacchino

Groovy: chiamare i metodi per nome…

…e come se no? Questa volta vi mostro un piccolo esempio di come è possibile invocare dinamicamente un metodo di una classe chiamandola “per nome”, ossia utilizzando una variabile di tipo “String” che contenga il nome del metodo. Benché l’esempio sia al solito parco di linee di codice comprenderete che fare una cosa del genere con un linguaggio tradizionale ne richiederebbe molte di più.

Ma procediamo con ordine; costruiamoci una classe che faccia al nostro scopo:

class Fagiolo{
    def parla(){
        "Sono un fagiolo, lasciatemi solo"
    }
    def parlaForbito(){
        "Sono un fagiuolo, alcun vorrei meco su questo suolo"
    }
}

Questa volta ho utilizzato qualche trucchetto in più del post precedente, giusto per mostrarvi la massima compattezza (e illeggibilità, dirà giustamente qualcuno) con cui si possono scrivere i metodi in Groovy: in questo i due metodi fanno cose molto simili ossia restituiscono una stringa; non avendo specificato la visibilità essi saranno pubblici e non avendo specificato lo statement “return” un metodo Groovy restituirà sempre l’ultimo dato elaborato; inoltre le stringhe, così come i numeri sono considerati instanze di relativi oggetti. Quindi quello che abbiamo scritto sono due metodi pubblici che restuiscono due stringhe.

Adesso completiamo lo script con le seguenti righe (incollate i due pezzi in GroovyConsole e testate con i vostri occhi l’imprevedibile risultato di questo codice):

metodi = ["parla","parlaForbito"]
fagiolo = new Fagiolo()
metodi.each{metodo -> println fagiolo."$metodo"()}

In questo caso ci siamo creati un array di stringhe che contiene i nomi dei metodi, abbiamo creato un’istanza della classe Fagiolo ed abbiamo richiamato i metodi della classe come

fagiolo."$metodo"()

ossia abbiamo chiamato il metodo “per nome”. Notate che metodi.each{} presuppone, all’interno delle parentesi la definizione di un closure, ossia un metodo anonimo definito in linea che ha come parametro la variabile metodo che, ad ogni iterazione assume il valore di uno degli elementi dell’array “metodi” e viene passato ad un metodo, creato dinamicamente che invoca il metodo relativo dell’oggetto “fagiolo”.

Aldilà dell’esempio limitato e facile immaginare come potremmo scriptare una sequenza arbitraria di chiamate ai metodi di una classe ed ottenere dinamicamente il comportamento desiderato.

Zac

Persistenza e Modelli in Groovy e Java

Continuo il diario della mia esperienza Java e Groovy parlando di una libreria per la persistenza dei dati e di una scappatoia per realizzare derivati di AbstractTableModel in modo rapido: ovviamente sfruttando la capacità di Groovy di essere compilato in byte code e quindi di integrarsi con il resto dell’applicazione sviluppato in Java.

Per la persistenza dei dati sto utilizzando la libreria JPersist (di cui ignoro ancora le performance) che consente di accedere ai dati secondo il paradigma Object Oriented. A differenza dei framework di persistenza classici (compresi quelli integrati di Java) JPersist non ha bisogno di troppi file xml (a parte uno in cui scriviamo i parametri di connessione al DB.

Per accedere ai dati abbiamo bisogno di una classe che abbia lo stesso nome della tabella (o quasi uguale) e (per la scrittura dei dati) sia derivata da jpersist.PersistentObject; impostiamo come attributi della classe, i campi della tabella relativa e, fatto questo, avremmo bisogno di sbobinarci la solita pippa sulle proprietà di una classe Java ossia scrivere i metodi getter e setter dei relativi attributi. Oggigiorno questo non è più un problema ma (chissà se mai lo capiranno alla Sun) si perde in leggibilità. Molto meglio rivolgersi a Groovy per la realizzazione di una classe persistente; al solito, non meravigliatevi della brevità del codice:

import jpersist.*

public class Customer extends PersistentObject{
    Integer id
    String firstName
    String lastName
    
}

Niente virgole, niente getter e setter…nient’altro. Mi aspetto che nel DB esista una tabella Customer o customer o customers o qualsiasi nome *customer* con i campi id, firstname e lastname.

Vi rimando alla documentazione di JPersist per ulteriori dettagli su come fare le query, gli update, etc.

Vi parlo invece di come visualizzare i dati: per farlo abbiamo bisogno di una JTable o, meglio, di una JXTable, e di un TableModel. Per fare un TableModel ci vuole il legn…ehm…i dati e un modo per accedervi. Dobbiamo definire le colonne ecc, ecc.
Preleviamo i dati. Io ho realizzato un metodo per prelevare un’arraylist di clienti:

public ArrayList getCustomers() {
 try {
       DatabaseManager dbm = DatabaseManager.getXmlDefinedDatabaseManager("mio_db_definito_nel_file_xml");
       ArrayList result = (ArrayList) dbm.loadObjects(new ArrayList(), Customer.class);             
       dbm.close();
       return result;            
 } catch (Exception ex) {  }
 return null;
}

Ora mi serve il TableModel che costruirò sulla base di questo ArrayList; siccome a me piace molto il codice generico e poco lungo, l’ho scritto in Groovy usando la reflection:

import java.util.ArrayList;
import javax.swing.table.AbstractTableModel;
import groovy.swing.SwingBuilder
import java.lang.reflect.Field;

class GModel{
    private static Class getFieldType(Object o, fieldName){
        Field f = o.getClass().getDeclaredField(fieldName);
        return f.getType();
    }
    
    public static AbstractTableModel getModel(ArrayList dataList, 
                                        String[] fieldNames, 
                                        String[] fieldLabels){      
        def swing = new SwingBuilder() 
        def i=0;
        def gModel
        if (dataList.size()>0){
          Object o = dataList[0];
          gModel = swing.tableModel(list:dataList) { 
            fieldNames.each{                
              propertyColumn(header:fieldLabels[i], propertyName:it, type:getFieldType(o,it)) 
              i++
            }
          }
        }
        else
        {
          gModel = swing.tableModel(list:dataList) { 
            fieldNames.each{                
              propertyColumn(header:fieldLabels[i], propertyName:it) 
              i++
            }
          }  
            
        }
        return gModel
    }	
}

Il metodo statico getModel consente di fornire una lista di oggetti, un elenco di campi da visualizzare e le label delle relative colonne (ok avrei potuto utilizzare anche una Map). Tale metodo usa il SwingBuilder di Groovy per creare il table model in modo davvere eccezionale: provate a confrontare la routine con i table model scritti in java; ve lo ripropongo per maggiore dettaglio:

def swing = new SwingBuilder() 
def i=0;
def gModel = swing.tableModel(list:dataList) { 
    fieldNames.each{                
         propertyColumn(header:fieldLabels[i], propertyName:it, type:getFieldType(o,it)) 
         i++
    }
}

Quindi i dati li passo con l’attributo list di swing.tableModel ed al table model aggiungo (per ogni campo scelto) una propertycolumn che presenta una label, il nome dell’attributo (della classe Customer) ed il tipo del campo. A sua volta il tipo del campo lo recuperiamo genericamente usando la reflection.

private static Class getFieldType(Object o, fieldName){
    Field f = o.getClass().getDeclaredField(fieldName);
    return f.getType();
}

Penso che non serva passare un’istanza dell’oggetto ma sinceramente non ho avuto molto tempo per le ottimizzazione (volevo usare i generics ma non ci sono riuscito). Ad ogni modo il metodo recupera la classe ed il campo relativo al nome dell’attributo e ne restituisce il type.

Il table model così creato presenterà, una volta compilato, tutti i metodi, getter e setter di un table model classico. Stessa qualità, stesse performance meno codice!

Se avete suggerimenti e migliorie commentate pure

Zac

P.S.: In entrambi i metodi della classe lo statement “return” è superfluo dato che ogni metodo Groovy capisce dinamicamente quale delle sue variabili deve restituire.

Come ho fatto a non pensarci prima…

Dite la verità, e siate sinceri, su quanti di voi utilizzano un modo così snello di fare quegli odiosissimi if…else if…else if…else. L’articolo originale lo trovate qui ma ve lo ripropongo su KIT data la sua brevità.

Normalmente quando dobbiamo effettuare delle scelte utilizziamo un costrutto del genere (sia in C++, C# o Java)

if (token == "A")
  tokenNumber = 1;
else if (token == "B")
  tokenNumber = 4;
else if (token == "C")
  tokenNumber = 5;
else if (token == "X")
  tokenNumber = 10;
else
  tokenNumber = 20;

In realtà si può utilizzare un costrutto più immediato, più veloce da scrivere e da leggere e che produce lo stesso (meta)compilato…

tokenNumber = (token == "A") ? 1:
              (token == "B") ? 4:
              (token == "C") ? 5:
              (token == "X") ? 10:
              20;

Quant’è bello diffondere la conoscenza…

Zac

Il futuro non è più quello di una volta…

Fino a poco tempo fa pensavo che .Net (in quanto prodotto Microsoft) stava avanzando così tanto da buttare fuori di scena tutti gli altri modelli di sviluppo presenti sulla scena. In realtà per come la Microsoft sta giocando la sua partita .Net avrà senso solo finché Windows manterrà la sua quota di mercato. Ma forse bisogna guardare con più attenzione ai seguenti fatti:

  • sui desktop, Windows è ancora la scelta obbligata dato che le aziende che producono software e periferiche offrono quasi sempre soluzioni per Windows
  • il web, di contro, è permeato ancora di PHP, JSP di Apache e MySQL, per quanto, a livello enterprise ASP.NET, IIS e SQL Server, per via della loro stretta integrazione e user-friendliness (apparente), non sono certo una realtà minore
  • rispetto a qualche anno fa, esistono molte più piattaforme non-windows con cui fare i conti: lato mobile gli attori protagonisti sono Nokia, BlackBerry e iPhone; Microsoft dice che loro hanno un quota di mercato rilevante ma il dato, secondo la mia opinione, riguarda solo gli utenti di tipo aziendale (e tra questi manager e rappresentanti); mi sembra che tra i normali consumatori la piattaforma di riferimento sia Nokia
  • Java si è giocata la carta dell’open source e si contende, insieme a Mono, lo scettro di ambiente di sviluppo multipiattaforma per eccellenza: basta vedere la corsa ai nuovi ambienti di sviluppo per iPhone che, nonostante le limitazioni della licenza dell’SDK, è appena iniziata; guardate qui e qui
  • Java, dopo un periodo di sonnolenza, sembra aver ripreso la voglia di essere un competitor serio anche per le applicazioni desktop: ultimamente librerie come SwingX, Timing Framework o Jgoodies e ambienti di sviluppo maturi come NetBeans ed Eclipse dimostrano che lo sviluppo con Java non ha nulla da invidiare a .Net o Flash; inoltre il JCP, ovvero la comunità Java che decide come orientare le novità del linguaggio, è attiva più che mai per renderlo un linguaggio al passo coi tempi: sulla scena i linguaggi “minori” come Python, Ruby, Groovy e Javascript dimostrano giorno per giorno le loro indubbie qualità (type inference, definizione dinamica di metodi ed attributi, estensioni delle classi, presenza dei closures) e la capacità di Java di integrarli per ora lo sta salvando dal confronto diretto con il più giovane e performante C#; i grandi nomi dietro a Java dicono che non è possibile mantenere Java un linguaggio così semplice: è vero che le cose che fa C# si possono ottenere lo stesso ma la complessità necessaria per farlo scoraggia i più; Microsoft ha dimostrato che ha conoscenza ed esperienza da vendere nell’ambito dei linguaggi di sviluppo: LINQ, Parallel FX, e altri progetti dell’area Research stanno lì a dimostrarlo; di certo Java non può rimanere a guardare (e per fortuna non lo fa)
  • a proposito di Flash, va ribadito che ormai sono molti i progetti open source il cui output è un file Flash; la stessa Adobe inoltre ha da poco rilasciato la suite Air, che consente di portare le applicazioni flash sul desktop
  • Internet Explorer, sebbene sia il browser più diffuso, se la deve vedere con Firefox, Safari e all’orizzonte appaiono progetti come questo, molto interessante per le opportunità che presenta
  • non ultimo, il sistema operativo: Windows Vista ha avuto il grandissimo merito di dirottare molti utenti verso altri sistemi operativi ed ha convinto molti governi a scegliere alternative open source ai suoi prodotti; da questo punto di vista possiamo certamente dire che Microsoft è stata un grosso sponsor per il movimento del Software Libero; inoltre sulla scena, Apple si fa sempre più presente grazie alla riconosciuta qualità del suo sistema operativo e alla bellezza dei suoi prodotti: riuscendo inoltre ad attingere a piene mani da tutti i progressi del mondo Gnu/Linux e FreeBSD, Mac OS X sembra sempre più la piattaforma di sviluppo ideale per tutti i progetti non .Net (ricordo che da poco è stato rilasciato anche MonoDevelop per Mac OS X)

Insomma, sul palcoscenico ci sono molti attori e, forse, rispetto a qualche anno fa, la conoscenza diffusa delle alternative possibili rende i grossi nomi meno capaci di dirottare le scelte del mercato con semplici strategie di FUD (ossia instillare il dubbio che scegliere prodotti alternativi produca perdite, disastri e cataclismi di varia natura). Il modello di sviluppo open source risulta vincente a tal punto che grosse compagnie decidono di acquistarli in blocco piuttosto che derivarne lo sviluppo.

Vedremo cosa ci riserverà questo incerto futuro.

Qualche dettaglio: per chi non lo sapesse Lobo Browser è un browser web open source scritto interamente in Java. Nell’ultima release integra il rendering di applet JavaFX, ossia il nuovo concorrente di Flash nell’ambito Web.

Zac

Da oggi siamo Mobail

Posted by mobile phone:
Per la gioia di quanti, come me, usano accedere ad internet dal cellulare o dal palmare, da oggi Keep In Tech è anche mobile, per una consultazione più rapida ed agevole. Ovviamente ho scritto questo post dal mio cellulare!

Quindi ora non avete più scuse per non seguirci numerosi!!!

Fracture: Parallelizzare Java

Per sfruttare al meglio la potenza di elaborazione messa a disposizione da processore multicore (che ormai crescono nei nostri computer con la stessa rapidità della legge di Moore) occorre pensare i propri algoritmi in modo opportuno. Tempo fa accennammo all’esistenza di PLINQ (poi divenuta Parallel FX), una libreria per C# che consente di elaborare in parallelo le chiamate fatte durante i cicli for e for-each o, più in generale, parallelizzare le query LINQ.

Adesso esce Fracture, libreria per Java che ripresenta lo stesso paradigma. Il vantaggio principale di sfruttare una simile libreria, rispetto all’implementazione dei thread (che comunque vengono gestiti perfettamente dalle CPU multi-core) è che il codice scala automaticamente in funzione del numero di core presenti; tipicamente un software che sfrutta i thread viene scritto per parallelizzare certe procedure ma non si creano tanti thread quanti sono i processori; ma anche se così non fosse la libreria, spendendo qualche ciclo di clock di overhead, sicuramente consente uno sviluppo più agile ed una leggibilità del codice superiore, a tutto vantaggio della manutenibilità del codice.

Inoltre, librerie come la JTS (Java Topology Suite) potrebbero essere estese senza troppe difficoltà in modo da sfruttare al meglio le risorse a disposizione.

Ecco un esempio di codice Fracture:

Fracture.forEach(equations, new IProcessor() {
  public void processElement(DifferentialEquation deq) {
    solve(deq);
  }
});

Semplice e compatto. In questo caso

Per ora è tutto. Saprò dirvi qualcosa in più appena avrò fatto qualche esperimento (d’altronde era la libreria che aspettavo per la prossima release del mio algoritmo sul nesting…YUM!).

Zac

Cache Management con il Pattern Singleton

Così come promesso nel precedente articolo, in seguito alla soluzione proposta dallo stimato Marco Carlini, voglio mantenere la parola e scrivere questo articolo sul cache management.

Per chi non avesse letto il mio precedente articolo sulla Business Delegate, il problema evidenziato era dato dal fatto che veniva adottata l’onerosa Reflection per istanziare a runtime le classi di Business.

La soluzione proposta da Marco è stata quella di adottare un sistema di Chache Management per memorizzare, una volta istanziate, le classi di Business così da risparmiare le risorse almeno nei richiami successivi.

Trovandoci in ambito J2EE e avendo sfruttato il framework web Struts, la prima cosa venuta in mente per mettere, passatemi il termine “la pezza” :) , è stata quella di inserire queste classi nella Session, ma… da sempre ho trovato inserire oggetti in session come mettere in uno sgabuzzino tutti gli oggetti a cui non sappiamo trovare una sistemazione e quando dobbiamo andare a ritrovarli… ahi… che sorprese.

Oltre che poco nobile come soluzione, per trovarne una degna di tale nome, mi sono posto le seguenti domande:

Inserire gli oggetti in session è una soluzione di sicuro semplice, nel momento in cui stiamo inserendo il valore, ma è altrettanto semplice quando (e per chi) la si vuole ritrovare?

Mettiamo il caso che stiamo lavorando con un’applicazione Java, come un’Applet, non avendo sessioni, come possiamo memorizzare i dati e mantenerli persistenti?

La session ovviamente non è la risposta a queste due domande.

“La soluzione migliore è sempre la più semplice”. Io interpreto questa frase nel seguente modo, la soluzione per essere semplice deve esserlo sempre, semplice anche per chi la sfrutta e non solo per chi la realizza.

Senza andare tanto lontano e trovare soluzioni “poco semplici” la GoF come sempre ci viene incontro e ci fornisce una soluzione veramente semplice sia per chi la realizza che per chi la utilizza attraverso il Pattern Singleton.

Così come si può leggere su numerosi libri e su Internet, il pattern Singleton può essere implementato in diversi modi e appassiona molti studiosi . In particolar modo mi ha colpito la soluzione del Prof. Bill Pugh il quale fornisce una soluzione… semplice :) come serve a noi.

public class Singleton {

private static Singleton singleton = null;

private Singleton(){}

public static Singleton getInstance(){

if(singleton == null) singleton = new Singleton();

return singleton;

}

}

 

o ancora meglio (il final ci dà la certezza)

private Singleton() {}

/**
* SingletonHolder è caricato alla prima esecuzione di Singleton.getInstance()
* o al primo accesso al SingletonHolder.instance , not before.
*/
private static class SingletonHolder {
private final static Singletoninstance = new Singleton();
}

public static SingletongetInstance() {
return SingletonHolder.instance;
}

Essendo privato, il costruttore può essere istanziato solo all’interno della classe, infatti come si vede, è il metodo interno getInstance() che controlla che la classe Singleton sia già stata istanziata almeno una volta. Se non è stata istanziata (singleton == null) provvede a farlo, altrimenti semplicemente ritorna la classe che è stata evidentemente istanziata prima. Da notare l’importanza del metodo statico, il quale nel momento in cui viene caricata la classe, in automatico viene memorizzata.

Questo è bellissimo e fa proprio al nostro caso, una classe intelligente che indistintamente dal fatto che noi sappiamo o no se è già stata istanziata se ne occupa lei di creare l’istanza e mantenerla in cache nella Virtual Machine restituendocela quando la richiamiamo. Ora che abbiamo creato la classe di base, al suo interno possiamo metterci tutte le variabili di cui abbiamo bisogno. Nel nostro caso abbiamo bisogno di memorizzare le classi di Business. Anche una semplice HashMap può fare al caso nostro, una mappa in cui inseriremo però solo le classi Business. La chiave sarà data dal nome della classe e il valore sarà la classe stessa.

public class Singleton {

private static Singleton singleton = null;

private HashMap businessClasses = new HashMap();

private Singleton(){}

public static Singleton getInstance(){

if(singleton == null) singleton = new Singleton();

return singleton;

}

public HashMap getBusinessClasses() {

return businessClasses;

}

public void setBusinessClasses(HashMap businessClasses) {

this.businessClasses = businessClasses;

}

}

E’ inutile dire che ovviamente sfrutteremo i getters e i setters per impostare e richiamare le classi nella nostra cache.

Il vecchio codice per istanziare una classe di business era il seguente

public class BusinessExample {

public static BusinessInterface getBusinessInterface(String businessClassName) throws ClassNotFoundException, InstantiationException, IllegalAccessException{

Class c = Class.forName(businessClassName);

BusinessInterface bus = (BusinessInterface)c.cast(c.newInstance());

businessClasses.put(businessClassName, bus);

return bus;

}

}

Come si vede, ad ogni richiamo, la classe verrà istanziata attraverso la Reflection, che sia stata già istanziata da un’altra chiamata o no.

Sfruttando invece la classe Sigleton appena realizzata possiamo ovviare a questo problema come segue

public class BusinessExample {

public static BusinessInterface getBusinessInterface(String businessClassName) throws ClassNotFoundException, InstantiationException, IllegalAccessException{

BusinessInterface bus;

Singleton singleton = Singleton.getInstance();

HashMap businessClasses = singleton.getBusinessClasses();

if(businessClasses.containsKey(businessClassName)){

bus = (BusinessInterface)businessClasses.get(businessClassName);

System.out.println(“business già presente nella WM”);

}else{

Class c = Class.forName(businessClassName);

bus = (BusinessInterface)c.cast(c.newInstance());

businessClasses.put(businessClassName, bus);

System.out.println(“classe istanziata con la reflection”);

}

return bus;

}

}

La riga

Singleton singleton = Singleton.getInstance();

ci ritorna semplicemente l’unica classe Singleton istanziata, non effettua una nuova istanza, quindi tutto ciò che è stato memorizzato al suo interno precedentemente ce lo ritroveremo in qualsiasi momento,è per questo motivo che possiamo fare il controllo attraverso la IF, se la chiave è presente o meno nella HashMap businessClasses, e solo se la classe Business cercata non è stata istanziata si provvederà a farlo attraverso la Reflection

Abbiamo aggiunto solo le classi di Business nella classe Singleton, che come abbiamo visto ha assunto il ruolo di CacheManager, ma se se usata opportunamente è semplice sfruttare al meglio questa classe.

Supponiamo infatti di dover inserire in cache il nostro Logger preferito, basterà semplicemente aggiungerlo nella classe Singleton

public class Singleton {

private static Singleton singleton = null;

private static Logger logger = null;

private HashMap businessClasses = new HashMap();

private Singleton(){}

public static Singleton getInstance(){

if(singleton == null) singleton = new Singleton();

return singleton;

}

public static Logger getLogger() {

return logger;

}

public static void setLogger(Logger logger) {

Singleton.logger = logger;

}

public HashMap getBusinessClasses() {

return businessClasses;

}

public void setBusinessClasses(HashMap businessClasses) {

this.businessClasses = businessClasses;

}

}

A differenza di quanto accade sfruttando la Session, con Singleton richiamare le variabili è semplicissimo, in quanto abbiamo i metodi elencati all’interno della classe stessa, senza impazzire a ricordarci il nome dell’attributo salvato nella Session.

Spero di essere stato all’altezza delle aspettative e spero che molti adottino questa soluzione quando si troveranno dinanzi ad un problema di cache management, se non vogliamo che la Gang of Four storca il naso :).