Program to an interface, not an implementation

<< Webcast GUISA, parte II | Home | .NET Architectures in the Real World >>

Program to an interface, not an implementation

Discussioni come questa sono un classico, e classica è la domanda: "devo definire i miei tipi base sotto forma di interfaccia o classe?" Il principio di design "program to an interface, not an implementation" [GoF, 18] sembrerebbe consigliare la prima ipotesi, apparentemente in contrasto con Cwalina che, nelle Design Guidelines, afferma: "Do prefer classes over interfaces". Chi ha ragione, quindi? Entrambi. Entrambi perchè il GoF è un libro scritto pensando a C++, un linguaggio nel quale le "interfacce" non esistono (e nemmeno ce ne sarebbe bisogno, vista la disponibilità della MI e la possibilità di definire classi astratte pure). Ergo, Gamma & c. non si riferiscono alle interfacce nel senso di "interface", bensì riferendosi agli "abstract types". Il senso del noto principio di design è quindi: "Programmate pensando ad una famiglia di tipi, e non per una loro specifica implementazione (e occhio alle dipendenze!)". Polymorphism anyone? <g>

Technorati tags: software architecture, design

posted @ martedì 23 gennaio 2007 22.52

Comments on this entry:

# re: Program to an interface, not an implementation

Left by Adrian Florea at 24/01/2007 3.34

"One question is whether you should always use a Java interfaces for that. An abstract class is good as well. In fact, an abstract class gives you more flexibility when it comes to evolution. You can add new behavior without breaking clients. In Java when you add a new method to an interface, you break all your clients. When you have an abstract class, you can add a new method and provide a default implementation in it. All the clients will continue to work. As always there is a trade-off, an interface gives you freedom with regard to the base class, an abstract class gives you the freedom to add new methods later. It isn't always possible to define an interface in an abstract class, but in the light of evolution you should consider whether an abstract class is sufficient"

- Erich Gamma

(continua qui: http://www.artima.com/lejava/articles/designprinciples.html)

# re: Program to an interface, not an implementation

Left by Luca Minudel at 24/01/2007 8.44

Questi sono i criteri di scelta tra classe base e interfaccia che ho raccolto: http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/ClasseBaseOppureInterfaccia.html

Dal lato pratico ad oggi mi sono trovato bene seguendoli.

# re: Program to an interface, not an implementation

Left by Andrea Saltarello at 24/01/2007 9.00

@Adrian: Ehm... hai referenziato *esattamente* l'articolo che ho linkato io sulla parola "senso"... <g>
@Luca: Concordo, in linea generale, con i criteri da te espressi, ma IMHO sarebbe meglio specificare (dato il contesto ".NET-oriented" del wiki) che essi sono decisamente orientati a C++ unmanaged: alcuni di essi ,infatti, in assenza di MI ed ereditarietà privata rischiano di rivelarsi controproducenti

# re: Program to an interface, not an implementation

Left by Attilio Gelosa at 24/01/2007 10.17

A livello strettamente personale preferisco le interfacce. Perché?
- Non è del tutto vero che solo con le classi astratte non rompo i client perché le interfacce permettono una ereditarietà… se quindi voglio aggiungere una funzionalità eredito la mia interfaccia e la implemento dove voglio.
- .NET non permette l’ereditarietà multipla di classi (e questo, a volte, può essere un *grosso* problema…).

Attilio