Sul blog di gilad bracha c’è un post che parla del perché i costruttori sono anti-oo.
Giovanni Corriga(finalmente ha un blog!), vi direbbe che è perché la gente continua a pensare agli “oggetti” invece che ai “messaggi”. In pratica cosa c’è che non va?

Fondamentalmente, che usando un costruttore alla java/c#/c++ si introduce un accoppiamento forte nel codice che andrebbe evitato. È una nozione abbastanza diffusa che uno dovrebbe scrivere codice relativo all’interfaccia e non all’implementazione, e invece usando i costruttori ci si lega invariabilmente a un certo modo di fare le cose. Esempio scemo:

DatabaseMapper dm = new DatabaseMapper()
dm.save(someObject)

A un certo punto vi rendete conto che DatabaseMapper potrebbe essere preferibile come singleton o come un riferimento a un pool di oggetti. In qualsiasi modo vogliate spostarvi dall’avere un oggetto sarete costretti a rompere l’interfaccia introducendo un metodo come getInstance() e nascondendo il costruttore.

In ruby, Smalltalk, python, perl e CL, invece, non esiste un concetto speciale di costruttore.
Un metodo è responsabile di allocare un oggetto. Un altro metodo è responsabile per l’inizializzazione. Infine, un comodo metodo di utilità si occupa di fare entrambe le cose.
Scrivendo

 dm = DatabaseMapper()
in python quello che in realtà accade è che richiamate il metodo __call__() il quale a sua volta alloca l’oggetto con __new__(), lo inizializza con __init() e lo restituisce.

Quando decidete di passare al singleton non dovete far altro che cambiare un metodo e tutto continua a funzionare correttamente.
Lo stesso discorso vale per ruby, solo che i metodi in questione sono new, allocate e initialize.

Smalltalk e common lisp, per quel che ne so, seguono lo stesso identico approccio, con la sola singola differenza che i metodi non hanno una visibilità ristretta ma sono pubblici. Nel post di gilad bracha si parla di Smalltalk dicendo che non forza il fatto che un oggetto sia inizializzato una sola volta, e immagino parli di questo, ma da buon programmatore dinamico io ritengo che si tratti di un non-problema.

Il linguaggio non deve costringere a fare cose stupide, ma non è utile trattare il programmatore da idiota.

Ad ogni modo credo sia interessante considerare come, ancora una volta, aggiungere un costrutto ad un linguaggio (i costruttori) ne diminuisca le potenzialità invece di aumentarle. Meditate gente, meditate.