[*] Quando usare una classe astratta e quando una interfaccia

[dops]

Girando in rete per trovare + "scuole di pensiero" che affrontano questo "dilemma" mi sono imbattuto nel pensiero dell'autore della guida alla programmazione oop di questo sito. Dice:

I metodi appartenenti a questa ultima tipologia (metodi astratti senza implementazione) (e che sono definiti nella classe astratta) prendono il nome di Metodi Astratti. Nel caso limite in cui una classe astratta contenga soltanto metodi astratti allora essa verrà catalogata più correttamente come interfaccia (vedasi paragrafo inerente le interfacce).

Ma è veramente così? usare quindi una interfaccia al posto di una classe astratta solo quando questa "classe" non implementa i metodi delegando questo compito alla classe che la eredita?
Che ne pensate?

[shodan]

Ma in che linguaggio? :master:

[alka]

Un'interfaccia la si usa quando ci si vuole riferire successivamente ad un oggetto che include l'implementazione di determinati metodi (quelli appartenenti all'interfaccia, appunto) indipendentemente dalla classe a cui appartiene l'oggetto e dalle classi da cui questa discende.

L'uso di una classe astratta, invece, fornisce uno scheletro che "permane" nelle classi discendenti e, laddove viene utilizzata o referenziata, si richiede un oggetto che appartenga ad una classe discendente che implementa tutti i metodi astratti previsti dalla classe base.

In certi linguaggi, si utilizzano anche le interfacce per implementare una specie di ereditarietà multipla.

[dops]

Originariamente inviato da alka
Un'interfaccia la si usa quando ci si vuole riferire successivamente ad un oggetto che include l'implementazione di determinati metodi (quelli appartenenti all'interfaccia, appunto) indipendentemente dalla classe a cui appartiene l'oggetto e dalle classi da cui questa discende.

L'uso di una classe astratta, invece, fornisce uno scheletro che "permane" nelle classi discendenti e, laddove viene utilizzata o referenziata, si richiede un oggetto che appartenga ad una classe discendente che implementa tutti i metodi astratti previsti dalla classe base.

In certi linguaggi, si utilizzano anche le interfacce per implementare una specie di ereditarietà multipla.

Non mi è molto chiaro.. nel senso che in termini di astrazione massima (quello che si dovrebbe cercare di ottenere con la programmazione oop) dovrei a questo punto utilizzare solo le interfacce anzicchè le classi astratte.. cioè mi riesce difficile legare concettualmente i membri di una classe astratta con la classe che la eredita.. che astrazione sarebbe?
Poi vabbè dipende dal livello di astrazione che si vuole ottenere credo.. (e qui ti chiedo aiuto).. in quanto potrei creare una classe astratta ma che resta nel contesto architettonico oppure creare una classe astratta indipendente dal contesto del software per cui la si crea, e mi sembra che a questo puntino le tue definizioni di interfaccia e classe astratta. help :master:

[alka]

Originariamente inviato da dops
Non mi è molto chiaro.. nel senso che in termini di astrazione massima (quello che si dovrebbe cercare di ottenere con la programmazione oop) dovrei a questo punto utilizzare solo le interfacce anzicchè le classi astratte.. cioè mi riesce difficile legare concettualmente i membri di una classe astratta con la classe che la eredita.. che astrazione sarebbe?

Io posso tranquillamente prevedere di creare una classe astratta al solo scopo di fungere da scheletro, implementando solamente parte dei suoi metodi e lasciandola in parte, prevalentemente o totalmente astratta.

Originariamente inviato da dops
Poi vabbè dipende dal livello di astrazione che si vuole ottenere credo.. (e qui ti chiedo aiuto).. in quanto potrei creare una classe astratta ma che resta nel contesto architettonico oppure creare una classe astratta indipendente dal contesto del software per cui la si crea, e mi sembra che a questo puntino le tue definizioni di interfaccia e classe astratta. help :master:

Trovo che tutto quello che hai scritto non abbia un proprio senso, o comunque non ho capito una mazza di quello che hai voluto dire. :master:

[dops]

Originariamente inviato da alka
Io posso tranquillamente prevedere di creare una classe astratta al solo scopo di fungere da scheletro, implementando solamente parte dei suoi metodi e lasciandola in parte, prevalentemente o totalmente astratta.


Trovo che tutto quello che hai scritto non abbia un proprio senso, o comunque non ho capito una mazza di quello che hai voluto dire. :master:

facciamo così: "non hai capito una mazza di quello che dicevo" stò a scherzà
E' che continuo a non capire quando usare l'una e quanto l'altra nonostante la tua spiegazione Quel "si richiede un oggetto che appartenga ad una classe discendente" non mi è per niente chiaro. Cmq intendevo semplicemente dire che credo si potrebbe pensare all'astrazione di una entità in due contesti: quello in cui la creo (il software per cui scrivo ad esempio una interfaccia) e quello in cui potrei riutilizzare la stessa interfaccia.. vabbè a parte questa cosa.. vorrei porre un esempio pratico:

Mettiamo che voglia creare una assembly (.net) per la gestione delle prenotazioni. Prenotazioni di tutti i tipi.. che ne sò .. ad esempio la prenotazione di un biglietto del treno piuttosto che la prenotazione di una camera d'albergo. La prima cosa che mi viene in mente è quella (siccome vorrei astrarmi il + possibile dai tipi di prenotazione) di creare come dici tu uno scheletro che "vada bene" per tutti i tipi di prenotazione che andrò ad implementare. Quindi penso ad una interfaccia che conterrà la dichiarazione di proprietà e metodi che nessuna classe che eredita da questa interfaccia non potrà implementare. Ad esempio tutti i tipi di prenotazione hanno un inizio ed una fine, oppure tutti i tipi di prenotazione hanno un codice identificativo, o ancora tutti i tipi di prenotazione avranno una valuta (tipo euro, dollaro etc). Se questo è corretto, perchè stò pensando ad una interfaccia piuttosto che ad una classe astratta ??!! Non sono pazzo ed una spiegazione (tecnica) me la dò. Credo infatti che con una interfaccia, omettendo qualsiasi tipo di implementazione alle sue proprietà ed ai suoi metodi, renda veramente astratto e quindi riutilizzabile quello che contiene. Ma a questo punto sorge una domanda.. una interfaccia, che come sappiamo non deve contenere implementazioni ma solo dichiarazioni, non è totalmente uguale ad una classe astratta che allo stesso modo non contiene implementazioni ma solo dichiarazioni? Allora perchè cacchio dovrei usare l'interfaccia piuttosto che la classe astratta pura?

[alka]

Originariamente inviato da dops
La prima cosa che mi viene in mente è quella (siccome vorrei astrarmi il + possibile dai tipi di prenotazione) di creare come dici tu uno scheletro che "vada bene" per tutti i tipi di prenotazione che andrò ad implementare. [...] Ad esempio tutti i tipi di prenotazione hanno un inizio ed una fine, oppure tutti i tipi di prenotazione hanno un codice identificativo, o ancora tutti i tipi di prenotazione avranno una valuta (tipo euro, dollaro etc). Se questo è corretto, perchè stò pensando ad una interfaccia piuttosto che ad una classe astratta ??!!

Questo è un ambito in cui conviene utilizzare una classe, inserendo nella classe base tutte le caratteristiche (metodi e attributi) che sono comuni alle classi discendenti, che implementano invece i tipi specifici di prenotazione, aggiungendo nuove caratteristiche (metodi e attributi) che si riferiscono al tipo particolare di prenotazione.

Il perché tu stia pensando ostinatamente ad un'interfaccia, in questo caso, non lo so: la capacità di leggere nel pensiero non l'ho ancora sviluppata.

Originariamente inviato da dops
Credo infatti che con una interfaccia, omettendo qualsiasi tipo di implementazione alle sue proprietà ed ai suoi metodi, renda veramente astratto e quindi riutilizzabile quello che contiene.

Sì, ed è proprio per questo motivo che, in questo frangente, non ha senso utilizzarla (così come è posto il problema), visto che stai definendo delle caratteristiche per l'elemento "Prenotazione" del tuo sistema che hanno attributi e metodi che devono essere definiti in qualche modo.

Originariamente inviato da dops
Ma a questo punto sorge una domanda.. una interfaccia, che come sappiamo non deve contenere implementazioni ma solo dichiarazioni, non è totalmente uguale ad una classe astratta che allo stesso modo non contiene implementazioni ma solo dichiarazioni? Allora perchè cacchio dovrei usare l'interfaccia piuttosto che la classe astratta pura?

Una classe astratta può anche essere implementata parzialmente, avendo solo alcuni metodi astratti e non tutti.

Supponendo comunque che si stia parlando di una classe astratta in cui non viene implementato alcun metodo, prendendo ancora in esame l'esempio delle "Prenotazioni", non ha senso che io definisca la base di tutte le prenotazioni come interfaccia, visto che non si avrebbe a che fare con una gerarchia di oggetti a cui può essere opzionalmente applicata l'interfaccia "Prenotazione", ma la "Prenotazione" in sé rappresenta un elemento specifico, che ha attributi generici comuni, inseriti nella classe base, dalla quale erediteranno tutte le classi discendenti che rappresentano i tipi specifici di "Prenotazione" con cui si vuol avere a che fare.

In questo caso, ipoteticamente, un'interfaccia potrebbe tornare utile qualora si abbiano, oltre alle "Prenotazioni", altri tipi di oggetti, magari appartenenti a gerarchie diverse, e si volesse definire per questi un metodo specifico, ad esempio un metodo "Annulla", che si possa applicare sia alle prenotazioni ma anche ad altri oggetti di classi diverse, definendo così un'operazione che viene implementata in gerarchie di classi diverse ma che conserva un significato/comportamento analogo, consentendo di effettuare l'operazione di annullamento, ad esempio, su entrambi i tipi di oggetti eterogenei.

Migliaia di altri esempi a riguardo si possono trovare poi anche nella stessa libreria base del .NET Framework, giusto perché è stato citato, dove sono presenti migliaia di classi e interfacce.

Ciao!

[dops]

Originariamente inviato da alka
Questo è un ambito in cui conviene utilizzare una classe, inserendo nella classe base tutte le caratteristiche (metodi e attributi) che sono comuni alle classi discendenti, che implementano invece i tipi specifici di prenotazione, aggiungendo nuove caratteristiche (metodi e attributi) che si riferiscono al tipo particolare di prenotazione.

Il perché tu stia pensando ostinatamente ad un'interfaccia, in questo caso, non lo so: la capacità di leggere nel pensiero non l'ho ancora sviluppata.


Sì, ed è proprio per questo motivo che, in questo frangente, non ha senso utilizzarla (così come è posto il problema), visto che stai definendo delle caratteristiche per l'elemento "Prenotazione" del tuo sistema che hanno attributi e metodi che devono essere definiti in qualche modo.


Una classe astratta può anche essere implementata parzialmente, avendo solo alcuni metodi astratti e non tutti.

Supponendo comunque che si stia parlando di una classe astratta in cui non viene implementato alcun metodo, prendendo ancora in esame l'esempio delle "Prenotazioni", non ha senso che io definisca la base di tutte le prenotazioni come interfaccia, visto che non si avrebbe a che fare con una gerarchia di oggetti a cui può essere opzionalmente applicata l'interfaccia "Prenotazione", ma la "Prenotazione" in sé rappresenta un elemento specifico, che ha attributi generici comuni, inseriti nella classe base, dalla quale erediteranno tutte le classi discendenti che rappresentano i tipi specifici di "Prenotazione" con cui si vuol avere a che fare.

In questo caso, ipoteticamente, un'interfaccia potrebbe tornare utile qualora si abbiano, oltre alle "Prenotazioni", altri tipi di oggetti, magari appartenenti a gerarchie diverse, e si volesse definire per questi un metodo specifico, ad esempio un metodo "Annulla", che si possa applicare sia alle prenotazioni ma anche ad altri oggetti di classi diverse, definendo così un'operazione che viene implementata in gerarchie di classi diverse ma che conserva un significato/comportamento analogo, consentendo di effettuare l'operazione di annullamento, ad esempio, su entrambi i tipi di oggetti eterogenei.

Migliaia di altri esempi a riguardo si possono trovare poi anche nella stessa libreria base del .NET Framework, giusto perché è stato citato, dove sono presenti migliaia di classi e interfacce.

Ciao!

Che dire, grazie mille Quella dell'interfaccia che astrae completamente il concetto dal contesto è una cosa che avevo in mente, ma come l'avevo pensata io era alla fine una classe astratta. Grazie ancora.