sabato 26 maggio 2012

Do not merge the singleton pattern with the factory one!

Do you remember the programming school and what the teacher was repeating any lesson? "Using global state is a bad programming technique!" Singletons are nothing more than doing global state, even if in a more elegant way.

With the advent of many Java framework the singleton pattern was made so popular that pretty much every developer now know it. For those that still have doubts, a singleton is an object that exists in a "single" instance along the whole application/framework. As an example, many GUI libraries provide a "Display" class, which is a singleton (the library needs a single display to draw onto); other examples could be a shared resource or service. The idea is simple: does the program require access to always the same object? If yes is the answer, chances are a singleton will be used.
How is implemented a singleton? Often it is implemented using a factory pattern like in the following snippet:

public class Display{
       // make constructor private
       // so that nobody can build
       // an instance autonomously
       private Display(){ ... }


       // a static reference to the
       // ONLY available instance
       private Display mySelf = new Display();


       // use a factory method to get
       // an instance of the Display
       public final static Display getInstance(){
              return mySelf;
       }
      
}

The above example is kept simple just to show what and how a singleton is implemented; it is possible to make very complex and elegant implementations as well as to port the above code in any other programming language.
What is wrong with the above piece of code? That two patterns are involved: the singleton one and the factory one.
Now, singleton is bad, factory is good.
To explain the latter statement, allow me to introduce a piece of client code that is going to use the above Display class:

void showPopupWindow(){
     Display.getInstance().showPopupDialog( "Hello World" );
}

What is strange with the above code? The method has no parameters, and is not accessing any private instance of the class. Let's see from another perspective: the client code knows where to find and how to get the Display instance, and therefore it is going to obtain it. This is a very strong coupling, and make code hard to read and test. Why? Let's start from the coupling first: the client code is going to access directly the Display class, and therefore there is no way to "inject" another Display instance to use. The two classes are therefore strictly coupling. This leads to the hard-test problem: how are you supposed to test the showPopupWindow() method if you cannot inject a mock-up Display object? The only way is to uninstall the real Display and use a fake one. It is not so simple. Finally, the hard-to-read problem: imagine you have access to the Javadoc documentation, that is something like:

     /**
       * Shows a popup window on the user display.
       */
     void showPopupWindow();

You don't see what the code does in its implementation, so you have to guess that it is going to access the Display class to get an instance. Please note the use of the word "guess".
How is it possible to solve such problems? Let's start from the client code: adopt dependincy injection as follows

void showPopupWindow( Display display ){
     display.showPopupDialog( "Hello World" );
}

or use an internal variable to keep an injected instance of Display and access it. Then refactor the Display code to use a separate factory:

public class Display(){
       public Display(){ ... }
}


public class DisplayFactory{
       private Display instance = new Display();


       public static final Display getDisplayInstance(){
              return instance;               
       }
}


Note that the instance is now cached into the factory, and that the Display class is pretty normal now. You can use some fancy protection mechanism, like making the Display's constructor package-visible and not public, but you get the idea. Now, no matter how you implement the Display class, the factory pattern is implemented the right way and the coupling among classes is strongly reduced. Moreover, you can also distribute the Display in binary form letting the clients to reimplement the factory pattern, while in the former case you could not. This problem lies in the fact that the first implementation of the Display class was playing a double role: the singleton and the factory for itself. This in particular is very common in many programs (and I did also!) but it is wrong. Note I'm not saying "it could be" wrong. A class must be thought as a unit with as less aims as possible, in particular with a single aim. So the right way to go is using a class as a singleton and one as a factory. This requires much more code and a few effort for initial setup but will pay in the long term.

venerdì 25 maggio 2012

KDevelop e auto-brace

Kdevelop, l'IDE di riferimento del KDE è uno strumento sicuramente valido, ma che viene distribuito con una configurazione di base spartana e che evidenzia le differenze con IDE piu' famosi come Eclipse. Avevo già trattato in precedenza come l'auto-bracketing, ossia la chiusura automatica di parentesi e ticks, fosse una funzionalità quasi indispensabile nell'editor, ma che KDevelop implementa in modo debole fornendo una funzione "stupida" che non fa altro che inserire il simbolo di chiusura ogni volta se ne inserisce uno di apertura. Il funzionamento desiderato è un po' piu' complesso, e prevede che il simbolo di chiusura sia inserito solo se non già presente.
Guidato dai forum KDE e dal tutorial di Kate, che è il componente di editing di KDevelop, ho impostato un ambiente di sviluppo per Kate per debuggare la funzionalità di cui sopra, convinto che la sua implementazione non fosse difficoltosa.
Con piacevole sorpresa ho scoperto che tale comportamento è già implementato in Kate (e quindi in KDevelop) mediante un plug-in denominato autobrace che può essere abilitato anche da GUI (come da immagini qui sotto) e che sovrascrive il comportamento "stupido" di default.



CMake e sostituzione di variabili nei sorgenti

Se si sta compilando un progetto tramite CMake e si vuole avere la sostituzione di una variabile all'interno di sorgenti (che quindi devono essere compilati) è possibile usare le direttive set assieme a configure_file che con semplici passi consentono di ottenere lo scopo.
Ad esempio, si supponga di voler specificare un percorso come variabile definita al momento della compilazione: il file che contiene la variabile non ancora sostituito è config.h.in e deve essere modificato nel file generated/config.h:
  • nel file CMakeLists.txt occorre impostare una variabile, ad esempio XML_PATH con il valore desiderato:
set( XML_PATH "\"/tmp/roles.xml\"" )
configure_file( config.h.in ${CMAKE_BINARY_DIR}/generated/config.h )

  • sempre nel file CMakeLists.txt occorre indicare al compilatore di usare il file generato da CMake stesso invece che quello originale (senza la sostituzione della variabile):



include_directories( ${KDE4_INCLUDES} . ${CMAKE_BINARY_DIR}/generated/ )




  •  nel file che deve essere sottoposto a espansione di variabile si deve usare la sintassi speciale @NOME-VARIABILE-CMAKE@:
#define XML_SYSTEM_ROLES_REPOSITORY_PATH @XML_PATH@



lunedì 14 maggio 2012

Qt Creator 2.5

E' uscita oggi la nuova versione del Qt Creator, la 2.5, che fra le altre migliorie include un minimale supporto per l'azione extract method in modalità refactoring. Ho provato quasi subito la funzione e devo dire che il supporto è proprio minimale: del metodo da estrarre viene chiesto solo il nome e non il prototipo. Questo significa che non è possibile specificare tipo di ritorno e lista dei parametri, come pure la visibilità (default a public). Anche il punto di inserimento del metodo appare abbastanza rudimentale, visto che il metodo viene messo subito prima quello corrente spostando anche gli eventuali commenti che risultano quindi sbagliati. Insomma, c'è ancora molto lavoro da fare, ma sono sicuro che una volta completata questa feature darà i suoi frutti.
Apparentemente la versione di FreeBSD presente nei ports è ancora la 2.0.1, come pure quella disponibile come PBI, anche se il port è stato aggiornato e molto presto lo sarà anche il PBI.

domenica 13 maggio 2012

Ottenere lo username e il nome del gruppo principale in Linux

Seppur semplice e scontato, riporto qui un pezzo di codice C che consente la scoperta dello username dell'utente che sta attualmente eseguendo l'applicazione e l'ottenimento del nome del primo gruppo a cui l'utente appartiene:

QString getUsername()

  // get the data about the user using the getpwuid(2) system call
  uid_t  currentUID_t   = getuid();
  struct passwd *st_pwd = getpwuid( currentUID_t );
 
 
  if( st_pwd != NULL )
    // convert the string with the username into a "good" string
    return QString::fromLatin1( st_pwd->pw_name );
  else
    // error !
    return QString::number( currentUID_t );
}


QString getGroupname()

  // get the data about the user using the getpwuid(2) system call
  uid_t  currentUID_t   = getuid();
  struct passwd *st_pwd = getpwuid( currentUID_t );
  gid_t currentGID_t     = getgid();
 
  int ngroups = 1;      // number of groups to be retrieved
  gid_t *st_groups;
  st_groups = (gid_t*) malloc( sizeof( gid_t ) * ngroups );
  getgrouplist( st_pwd->pw_name,
                currentGID_t,
                st_groups,
                &ngroups
  );
 
 
  if( st_groups != NULL ){
    // convert the string with the username into a "good" string
    group* groupID = getgrgid( st_groups[0] );
    return QString::fromLatin1( groupID->gr_name );
  }
  else
    // error !
    return QString::number( currentGID_t );
}


Le due funzioni restituiscono entrambe un oggetto QString che può quindi essere utilizzato in una applicazione Qt/KDE. Nel caso particolare di KDE conviene invece utilizzare l'oggetto di libreria KUser che alla sua creazione effettua autonomamente l'aggancio allo username e alla lista dei gruppi:

KUser user;
user.loginName();
user.groupNames().at( 0 );




sabato 12 maggio 2012

Variabili multicolore

KDevelop è l'IDE di riferimento per lo sviluppo KDE, e io lo uso anche come IDE per progetti php. Una caratteristica interessante dell'IDE è la colorazione delle variabili: ad ogni nome di variabile l'IDE associa un colore random (fino ad un certo numero di scelte, dopodiché il colore rimane lo stesso verde scuro). Il risultato è che il codice appare molto colorato come mostrato qui sotto.

Se comparato al cugino QtCreator o al piu' famoso Eclipse, questo effetto arcobaleno può a prima vista spiazzare e sembrare esagerato. Quello che segue è un frammento di codice in QtCreator (notare che le variabili hanno tutte lo stesso colore rosso):


Ancora piu' scarno risulta lo stesso pezzo di codice del primo esempio in Emacs:

 

Ma serve realmente l'effetto di colorazione di KDevelop? 
All'inizio ero piuttosto scettico, e questo effetto rainbow mi distraeva piu' che aiutarmi. A forza di lavorare con questo IDE però ho compreso l'utilita' di questa funzione, che illustro con un esempio pratico:

 

Ovviamente il pezzo di codice di cui sopra è volutamente ridicolo e ha il solo scopo di mostrare l'uso della colorazione random delle variabili. Notato nulla di sbagliato? Si sta invocando il metodo QString.toAscrii() su una variabile sbagliata, che non è di tipo QString. In questo caso quindi la colorazione delle variabili ci permette di identificare anche il tipo delle variabili (entro certi limiti) e di capire che la variabile alla quale si fa riferimento è effettivamente quella desiderata e non un'altra variabile dal nome simile. Il caso di cui sopra si sarebbe potuto evitare anche con l'uso della code completion di KDevelop (e di ogni buon IDE), ma si pensi a cosa succede nel caso di utilizzo di un operatore: in tale situazione l'identificazione visiva rapida di una variabile permette di evitare grossolani errori.