un pratico esempio del perchè l'Object Oriented non è la Soluzione Universale©'

January 13, 2016

Ieri molti amici e lettori mi hanno chiesto perchè avessi iniziato ad approfondire il paradigma funzionale, quando con l'object oriented riesci a risolvere quasi tutti i problemi del mondo.

Voglio farvi vedere un esempio di codice che, siccome dipende dallo stato interno degli oggetti e questo stato è mutevole, risulta molto difficile da seguire e da analizzare.

Stavolta l'esempio l'ho preparato in Java, il linguaggio OO per eccellenza. Ho creato la classe “Stormo (di gabbiani)” che modella uno stormo. Ogni stormo ha due metodi, il metodo “unisci ” con un altro stormo, e “riproduci“, che modella essenzialmente quella cosa là :D.

Nel main invece vedete un po' di operazioni sugli Stormi. Quanto vale result?

class Stormo {

	public int gabbiani;

	public Stormo(int n) {
		this.gabbiani = n;
	}

	public Stormo unisci(Stormo other) {
		this.gabbiani += other.gabbiani;
		return this;
	}

	public Stormo riproduci(Stormo other) {
		this.gabbiani = this.gabbiani * other.gabbiani;
		return this;
	}
}

public class Test {

	public static void main(String args[]) {

		Stormo stormo_a = new Stormo(4);
		Stormo stormo_b = new Stormo(2);
		Stormo stormo_c = new Stormo(0);

		int result = stormo_a.unisci(stormo_c).riproduci(stormo_b)
                  .unisci(stormo_a.riproduci(stormo_b)).gabbiani;

		System.out.println(result);
	}
}

Quanti gabbiani contate? Quanto vale result alla fine del Main ?

La risposta che avete contato voi è ... 16. La riposta del compilatore invece è ... 32. E l'oggetto stormo_a è addirittura cambiato!

Come vedete, sono bastate poche righe di codice per ottenere un risultato sballato e un bug piuttosto evidente.

Uno dei problemi che affligge questo codice è che va a mutare lo stato interno dell'oggetto; se i metodi unisci e riproduci avessero restituito copie e lasciato immutato la classe stessa, ora non saremmo qui a parlarne.

EDIT:

Amici suggeriscono di mostrare cosa si dovrebbe cambiare affinchè il codice funzioni.

Io modificherei i metodi unisci e riproduci per ottenere il risultato corretto:

public Stormo unisci(Stormo other) {
    return new Stormo(this.gabbiani+other.gabbiani);
}

public Stormo riproduci(Stormo other) {
     return new Stormo(this.gabbiani*other.gabbiani);
}

Ed è qui che si applica il concetto di immutabilità: non ci sono side effects sull'oggetto chiamato e viene restituito un nuovo oggetto contenente le nuove proprietà.

Dunque ciò che dicono i miei amici e colleghi è giusto, nel senso che con la programmazione a oggetti (ma anche con la programmazione iterativa) i problemi si risolvono comunque; l'approccio funzionale permette però di avere qualche altro gadget nel coltellino svizzero del programmatore, di scrivere codice più bello, più espressivo, più succinto.

Per completezza, riporto qui l'esempio (con i termini inglesi) in javascript così potrete eseguirlo nella console del browser (senza che aprite eclipse...). Anche questo esempio è preso da Mostly Adequate Guide to Functional Programming, capitolo 1.

var Flock = function(n) {
  this.seagulls = n;
};

Flock.prototype.conjoin = function(other) {
  this.seagulls += other.seagulls;
  return this;
};

Flock.prototype.breed = function(other) {
  this.seagulls = this.seagulls * other.seagulls;
  return this;
};

var flock_a = new Flock(4);
var flock_b = new Flock(2);
var flock_c = new Flock(0);

var result = flock_a.conjoin(flock_c)
    .breed(flock_b).conjoin(flock_a.breed(flock_b)).seagulls;
//=> 32