lunedì 9 aprile 2012

Riflettiamo con la Java Reflection

L'idea di questo post nasce da un test preselezione che ho fatto per un'azienda inglese. Dato un pezzo di codice veniva chiesto quale caratteristica del linguaggio Java era utilizzata. Si trattava della reflection.

La reflection è quella caratteristica del linguaggio Java che permette ad un programma  in esecuzione di accedere a proprietà interne del programma stesso. Tutto ciò ovviamente in contro tendenza con il paradigma orientato agli oggetti. Ad esempio con questa caratteristica è possibile per un classe Java ottenere e accedere al nome di tutti i suoi metodi e attributi ed eventualmente mostrarli.

Perché la reflection?

La violazione del principio di incapsulamento dei linguaggi object oriented può essere pericoloso ma se trattato con le giuste accortezze diventa uno strumento potentissimo. In particolare può essere utile nei framework e in casi in cui si necessità di un forte riutilizzo di codice. Consideriamo ora un esempio di codice Java (fonte sito ufficiale della Oracle):


   import java.lang.reflect.*;
 
   public class DumpMethods {
      public static void main(String args[])
      {
         try {
            Class c = Class.forName(args[0]);
            Method m[] = c.getDeclaredMethods();
            for (int i = 0; i < m.length; i++)
            System.out.println(m[i].toString());
         }
         catch (Throwable e) {
            System.err.println(e);
         }
      }
   }


Per usare la reflection occore effettuare l'import del package java.lang.reflect.Ora richiamando la classe DumpMethods e passando come input la stringa "java.util.Stack" l'output che otteniamo è il seguente:


 public java.lang.Object java.util.Stack.push(
    java.lang.Object)
   public synchronized 
     java.lang.Object java.util.Stack.pop()
   public synchronized
      java.lang.Object java.util.Stack.peek()
   public boolean java.util.Stack.empty()
   public synchronized 
     int java.util.Stack.search(java.lang.Object)



otteniamo quindi l'elenco dei metodi della classe Stack compreso di parametri e il tipo restituito da ogni metodo.

Un ottimo esempio di come sia utile la reflection è nella conversioni di documenti XML in oggetti Java (più facilmente manipolabili all'interno di un applicazione scritta in linguaggio Java). Trovate un ottimo esempio di codice qui.

Infine per una illustrazione completa dei diversi usi della reflection date anche un'occhiata qui.

Eccomi di nuovo: qui London!

Eccomi di nuovo online! Ok la connessione internet ce l'ho da un pezzo qui a Londra ma era il tempo che mi mancava! Ora torno a scrivere nuovi post sul mio blog direttamente live from London!

Sono alla ricerca di un lavoro come informatico qui a Londra e devo dire che la vita è abbastanza dura. Ho fatto già un paio di colloqui e devo dire che sono abbastanza duri! Però spero di farcela il prima possibile. Per questo nel fra tempo mi sono trovato un lavoretto part-time anche per migliorare il mio inglese. Lavoro da Eat. Se passate qui da Londra vi consiglio di pranzare in uno di questi deliziosi negozietti.

Ora provvedo a pubblicare nuovi post e magari prossimamente pubblicherò qualche aggiornamento sui miei colloqui di lavoro e su come si svolgono qui a Londra.

See you soon!


mercoledì 8 febbraio 2012

Interview question: Repository Pattern e Factory Pattern

Oggi parleremo di Repository Pattern e Factory Pattern. Entrambi fanno parte della categoria dei Design pattern ossia quell'insieme di schemi di progettazione che permettono di risolvere problemi riccorrenti. Esistono diversi tipi di pattern che sono classificati in base a diversi criteri. Solitamente si sceglie di classificare i pattern a seconda del problema che trattano.
In questo post tratteremo due pattern in particolare: il Factory Pattern e il Repository Pattern. Il Factory Pattern rientra nella categoria dei "pattern creazionali" ossia tutti quei pattern che si nascondono i costruttori delle classi "camuffandoli" con metodi in modo che si possano utilizzare gli oggetti senza sapere come siano utilizzati (un po' come fanno le interfacce). Questo pattern aiuta a modellare un interfaccia per la creazione di un oggetto il quale nel momento in cui viene creato può permettere alle sue sottoclassi di decidere quale classe instanziare.



Questo pattern, come mostrato in figura, è usato quando la classe Creato non conosce in anticipo tutte le sue sottoclassi che andrà a creare. Invce è lasciata ad ogni sottoclasse, la ConcreteCreator, la responsabilità della creazione dell'istanza dell'oggetto corrente.

Il Repository Pattern fa parte dell'insieme dei pattern architetturali che non operano a livello di design e quindi non sono considerati veri e propri pattern. Questo pattern vuole evitare l'accesso diretto alle fonti dati come database, servizi web, liste sharepoint ecc. in quanto questo comperterebbe diversi problemi come codice duplicato, alto rischio di errori di programmazione, tipizzazione debole dei dati di business e cosi via. Cosa propone questo pattern? L'utilizzo di un repository per separare la logica di ritrovamento dei dati dalla logica di bussiness.


In questo modo la logica di bussiness e il data source non comunicano direttamente ma lo fanno solo attraverso i repository come mostrato in precedenza nella figura.


Si parte! Destinazione London!

Finalmente si parte. Il 22 febbraio sbarcherò a Londra (anche conosciuta come L'ondra) per dare inizio alla mia avventura. Avventura, di questo si tratta. Partirò per andare a cercare lì un lavoro nel mondo nell'informatica e realizzare il mio sogno: informatico inglese :-)
Sicuramente sarà un'avventura difficile e speriamo lunga. Sicuramente nei prossimi mesi l'esperienza mi cambierà. Speriamo in bene. Ho bisogno di una nuova sfida. Ho bisogno di stimoli. Ho bisogno di migliorare. Quale città meglio di Londra per iniziare!
Mi fermo qui e magari successivamente farò un post sulle emozioni che si provano nel pensare, organizzare ed iniziare questa avventura (magari appena arrivato a Londra).

Se mai un giorno qualcuno leggerà questo post, vedendo dove mi troverò in quel momento, capirà che io ci ho davvero creduto dall'inizio!


venerdì 27 gennaio 2012

Fai socializzare la tua app!

Ho scoperto di recente lavorando su una mia applicazione android un servizio davvero interessante. Il suo nome è socialize e permette di rendere la tua applicazione android o iOS più "sociale". In pratica è resa disponibile un Api gratuita che permette di aggiungere una barra contente diverse opzioni che rendono social l'app. Queste opzioni sono il classico "I like" stile facebook, un contatore delle visualizzazioni, la possibilità di condivisione del contenuto via facebook, email o sms e la possibilità di lasciare un commento anonimamente o loggandosi con il proprio account facebook. Ovviamente è possibile utilizzare anche il proprio account twitter invece dell'account di facebook.


Il servizio è gratuito se il traffico coinvolge meno di 100.000 utenti. Superate tale soglia occore comprare uno dei vari account premium proposti.
Ho inserito tale servizio nella mia applicazioni in quanto mi ha permesso in pochissimi passi di dare un aspetto social, che è tanto in voga oggi e comunque utile, alla mia applicazione.

Get Socialize!

giovedì 26 gennaio 2012

La storia di Android in 2 minuti


Ecco per voi un'immagine (fonte: http://www.xcubelabs.com) che riassume in 2 minuti tutta la cronologia delle varie versioni di Android dalla sua nascita ad oggi:



Perché le interfacce?

Molti si saranno chiesti a cosa servono e se sono realmente utili le interfacce software. Cercheremo di spiegarlo brevemente in questo post.

Un'interfaccia altro non è che una porzione di software che permette di interagire con le risorse hardware (memoria, CPU e cosi via) che si trovano ai livelli sottostanti. L'accesso a queste risorse se lasciato libero e indiscriminato può portare a diversi incovenienti. Per questo si può permettere l'accesso a tali risorse solo attraverso precisi entry point, ad esempio le interfacce.

Ma cosa è un'interfaccia nel campo della programmazione ad oggetti? Altro non è che una classe che non contiene dati, quindi di tipo astratto, e può contenere quindi solo metodi d'istanza astratti ( non può contenere né costruttori, né variabili di istanza, né metodi statici ecc.). Tuttavia una classe può implementare più interfacce. Una volta che una classe implementa un'interfaccia, il compilatore sà che un'istanza della classe conterrà lo specifico insieme di metodi. Per spiegare meglio cosa sia un'interfaccia usiamo un'analogia: un interfaccia seriale su un computer definisce un insieme di pin assegnati e il controlo dei segnali che saranno usati; il dispositivo può essere usato per differenti task: mouse, modem, ecc. e questi saranno tutti controllati attraverso lo stesso meccanismo di istruzioni digitali. Per cosa può essere utile un'interfaccia? Se una classe ha bisogno di due differenti insiemi di metodi cosi che il suo comportamente sia  quello di due cose differenti, può ereditare un insieme dalla classe A e usare un'interfaccia B per specificare l'altro!