Prinicipi di sviluppo SOLID in WinterCMS - I

Eccoci al terzo articolo di questa serie sui principi di sviluppo SOLID, in questo articolo vedremo per cosa sta e cosa dice il terzo principio definito con la "I" di Interface segregation principle

Interface segregation principle

A client should never be forced to implement an interface that it doesn't use or clients shouldn't be forced to depend on methods they do not use.

Una classe client non dovrebbe essere forzata a implementare interfacce che non usa, i client non dovrebbero essere forzati a implementare funzioni di cui non hanno bisogno.

Nel principio ISP, si cerca di suddividere le interfacce in modo che siano specifiche per i client che le utilizzano, evitando così di forzare i client a dipendere da metodi che non utilizzano.

In pratica questo vuol dire che è preferibile che le interfacce siano molte e specializzate invece che poche e generalizzate.

Supponiamo di avere un'interfaccia chiamata Animal che rappresenta un generico animale e definisce due metodi: eat() e fly().

interface Animal {
    public function eat();
    public function fly();
}

Ora, immaginiamo di avere due classi che implementano l'interfaccia Animal: Bird e Lion.

 class Bird implements Animal {
    public function eat() {
        echo "L'uccello sta mangiando.";
    }

    public function fly() {
        echo "L'uccello sta volando.";
    }
}

class Lion implements Animal {
    public function eat() {
        echo "Il leone sta mangiando.";
    }

    public function fly() {
        // Il leone non può volare, quindi questo metodo non ha senso per questa classe.
        // Dovremmo evitarlo nel contesto del principio ISP.
    }
}

Secondo il principio ISP, le interfacce dovrebbero essere suddivise in interfacce più specifiche. In questo caso, potremmo separare l'interfaccia Animal in due interfacce distinte: FlyingAnimal e EatingAnimal.

 interface FlyingAnimal {
    public function fly();
}

interface EatingAnimal {
    public function eat();
}

Rivediamo le classi Bird e Lion utilizzando le nuove interfacce appena create.

 class Bird implements FlyingAnimal, EatingAnimal {
    public function eat() {
        echo "L'uccello sta mangiando.";
    }

    public function fly() {
        echo "L'uccello sta volando.";
    }
}

class Lion implements EatingAnimal {
    public function eat() {
        echo "Il leone sta mangiando.";
    }
    // Il leone non implementa più il metodo fly(), che non ha senso per questa classe.
}

Ora le classi Bird e Lion implementano solo i metodi pertinenti alle rispettive funzionalità, evitando così l'implementazione forzata di metodi inutili o non applicabili.

Questo è solo un esempio semplice per illustrare il principio ISP. Nella pratica, il principio ISP può essere applicato in scenari più complessi per garantire una migliore separazione delle responsabilità e una maggiore coesione delle interfacce.

Anche per quanto riguarda la "I" è tutto, nel prossimo articolo vedremo il quinto e ultimo principio detto "Dependency inversion principle".

Happy coding!

Lunga vita e prosperità