Nexse SWAT Team

Lo scopo di questo articolo è quello di accennare alcuni principi indispensabili per sviluppare correttamente object oriented. Il post non vuole (e non può) essere esaustivo. Si vuole solo evidenziare l’importanza di conoscere questi argomenti per produrre software di qualità.

Perché sviluppare object oriented?
Una caratteristica fondamentale dei sistemi object oriented è quella di essere manutenibili. La manutenibilità di un sistema è una caratteristica importantissima che influisce sulla sua sopravvivenza. La vita di un sistema è caratterizzata dal cambiamento (ad esempio a causa dell’aggiunta di requisiti nuovi) e se la più piccola modifica comporta un costo molto alto, il sistema è destinato a vivere poco.

La pratica ha dimostrato come i sistemi object oriented siano più manutenibili. Questa caratteristica è dovuta a un mix di fattori, ad esempio: la semplicità nel mappare il dominio dei requisiti, quella di mostrare un’architettura chiara e la bassissima percentuale di codice duplicato.

Come sviluppare object oriented?
La prima alternativa è quella di affidarsi ai pattern, cioè a soluzioni a problemi ricorrenti distillate dall’esperienza di molti sviluppatori. Ma utilizzarli non è semplice, anche perché devono essere sempre adattati allo scenario di utilizzo. La seconda alternativa è quella di utilizzare direttamente i principi fondativi dei pattern. Se ci atterremo a questi è molto probabile che nelle nostre soluzioni riutilizzeremo un pattern, anche se inconsciamente.

Elenchiamo di seguito alcuni principi:

Open/Closed Principle (OCP): Una classe deve essere aperta alle estensioni ma chiusa alle modifiche.

L’OCP è indubbiamente il più importante dei principi. Il sistema che sto sviluppando deve essere strutturato in maniera tale che nel caso voglia aggiungere una nuova funzionalità non devo modificare il codice esistente.

Dependency Inversion Principle (DIP): Le classi che sviluppo devono dipendere da astrazioni e non da classi concrete.

La caratteristica di questo principio è quella di invertire la convenzione secondo cui uno strato software deve dipendere da uno strato più specializzato (da cui il nome). Il principio mette l’accento più che sul livello di specializzazione, sul fatto che le classi da cui dipendiamo devono essere astrazioni (interfacce o classi astratte).

Composite Reuse Principle (CRP): Bisogna favorire la composizione polimorfica degli oggetti piuttosto che l’ereditarietà.

Facciamo un semplice esempio in uno scenario di applicazione di gestione degli ordini. GestoreOrdini è la classe che ritorna un Ordine dato il nome ed il cognome, calcolando le spese di spedizione.

package it.nexse.swat.non_oo;
public class GestoreOrdini {
    public Ordine riempiOrdine(String nome, String cognome, int peso){
        int costoSpedizione = calcolaSpedizionePerItalia(peso);
        return new Ordine(nome, cognome, costoSpedizione);
    }

    private int calcolaSpedizionePerItalia(int peso){
            return 100*peso; //e se cambia il costo o l'algoritmo di calcolo?
    }
}

Nel caso in cui l’algoritmo di calcolo cambi sarò costretto a cambiare la classe (violazione dell’OCP). Modifichiamo il codice in modo da renderlo più manutenibile:

package it.nexse.swat.oo;

public class GestoreOrdini {
    private StrategiaDiCalcoloDelleSpeseDiSpedizione strategiaDiCalcoloDelleSpeseDiSpedizione;

    public GestoreOrdini(StrategiaDiCalcoloDelleSpeseDiSpedizione strategiaDiCalcoloDelleSpeseDiSpedizione) {
        this.strategiaDiCalcoloDelleSpeseDiSpedizione = strategiaDiCalcoloDelleSpeseDiSpedizione;
    }

    public Ordine riempiOrdine(String nome, String cognome, int peso){
        int costoSpedizione = strategiaDiCalcoloDelleSpeseDiSpedizione.calcolaSpedizione(peso);
        return new Ordine(nome, cognome, costoSpedizione);
    }

}

package it.nexse.swat.oo;

public interface StrategiaDiCalcoloDelleSpeseDiSpedizione {
    int calcolaSpedizione(int peso);
}

Abbiamo estratto la parte che potrebbe cambiare inglobandola all’interno di un’astrazione da cui la nostra classe dipende (adesione al DIP).

Ora, nel caso in cui si modifichi l’algoritmo di calcolo del costo della spedizione, la nostra classe GestoreOrdini non dovrà essere modificata. Abbiamo quindi creato un punto di estensione del codice (adesione all’OCP).

Potremo quindi implementare in diverse maniere la nostra interfaccia:

package it.nexse.swat.oo;

public class StrategiaDiCalcoloDelleSpeseDiSpedizionePerEstero implements StrategiaDiCalcoloDelleSpeseDiSpedizione{
    public int calcolaSpedizione(int peso) {
        return 200*peso;
    }
}

package it.nexse.swat.oo;

public class StrategiaDiCalcoloDelleSpeseDiSpedizionePerItalia implements StrategiaDiCalcoloDelleSpeseDiSpedizione{
    public int calcolaSpedizione(int peso) {
        return 100*peso;
    }
}

La semplice adesione al DIP ed all’OCP ci ha portato inconsapevolmente al riuso di un pattern: lo strategy pattern.

È importante sottolineare come non è necessario che tutto il codice dell’applicazione aderisca ai principi, perché questi a volte possono aumentare inutilmente la complessità del sistema. Quando si sviluppa bisognerebbe tuttavia sempre tenerli presente, ed ogni violazione dovrebbe essere una scelta consapevole.

Per approfondire:

• R.Martin – Design principles and design patterns
• K.Knoernschild – Java Design: Object UML and Process