Programmazione.it v6.4
Ciao, per farti riconoscere devi fare il login. Non ti sei ancora iscritto? Che aspetti, registrati adesso!
Info Pubblicità Collabora Autori Sottoscrizioni Preferiti Bozze Scheda personale Privacy Archivio Libri Corsi per principianti Forum
Differenze fra classi astratte e interfacce nella OOP
Scritto da Rocco Galati il 28-09-2011 ore 09:31
Intel Parallel Studio XE
Scrivere del buon codice, a volte, è solo una questione di piccole sfumature; può capitare che anche un programmatore esperto, con anni di esperienza, non abbia chiari alcuni concetti sulle definizioni e sull'utilizzo di alcuni strumenti messi a disposizione dal linguaggio che sta utilizzando: conoscere le differenze di una tecnica rispetto a un'altra può rivelarsi la chiave vincente per sviluppare un software robusto e veloce.

Ad esempio, alcuni programmatori ignorano le diverse caratteristiche che hanno le classi astratte e le interfacce, finendo con l'usarle indistintamente; scegliere una soluzione al posto dell'altra può complicare inutilmente il lavoro e generare un prodotto meno performante e più lento.

Una classe astratta è un particolare tipo di classe, che non può essere istanziata e che può unicamente essere ereditata da altre classi: funziona, quindi, come una base di partenza per la scrittura di più classi specifiche e che si rifanno tutte alla stessa classe iniziale. Un'interfacia, al contrario, è una classe che può essere vista come un insieme di dati e metodi visibili all'esterno degli oggetti, che sono istanze di quella stessa classe.

Dal punto di vista delle ereditarietà multiple, il framework .NET non ne prevede il supporto, quindi una classe può ereditare unicamente una sola classe astratta, mentre è possibile ereditare più interfacce.

Va evidenziato, ancora, che una classe astratta può definire un comportamento di default da utilizzare nel caso in cui una classe figlio non ne abbia implementato uno proprio, a differenza di quanto accade con le interfacce, in cui si può solo definire la firma dei metodi; infine, al contrario delle interfacce, le classi astratte forniscono accesso ai metodi per poterli modificare a seconda delle esigenze.

A seconda dei dati e della tipologia di progetto, è bene tenere a mente queste differenze, in modo da poter scegliere la tecnica migliore da adottare per ottenere i massimi risultati.
Precedente: Pro Android 3
Successiva: Migliorare le performance delle web application GWT con gQuery
Intervento di Domenico Sgarbossa a.k.a. sbraaa del 28-09-2011 ore 12:47, Padova (PD)
Nobile
Nobile
(93 interventi)
Iscritto il 29-03-2002
Le differenze sono chiare e le hai spiegate bene, quello che non colgo, è l'impatto sulle performance che può derivare dall'uso di una soluzione in luogo di un'altra. Sulla robustezza sono perfettamente d'accordo ma sulle performance non riesco a capire... ereditare una classe astratta è un'operazione più onerosa rispetto a creare una classe che erediti una o più interfacce?
Intervento di Rocco Galati a.k.a. roccogalati del 28-09-2011 ore 14:01, Torino (TO)
Nobile
Nobile

(96 interventi)
Iscritto il 07-12-2002
sbraaa ha scritto:
Le differenze sono chiare e le hai spiegate bene, quello che non colgo, è l'impatto sulle performance che può derivare dall'uso di una soluzione in luogo di un'altra. Sulla robustezza sono perfettamente d'accordo ma sulle performance non riesco a capire... ereditare una classe astratta è un'operazione più onerosa rispetto a creare una classe che erediti una o più interfacce?

A livello puramente teorico, un'interfaccia è considerata essere più lenta perchè occorre scorrere tutto l'oggetto per trovare il metodo corrispondente alla chiamata.

Dal punto di vista pratico, le differenze sono nulle dato che ormai l'hardware a disposizione di ogni macchina è elevato; certo, se si sta sviluppando un software che deve avere le prestazioni massime, allora converrebbe, se proprio si vuole, fare dei test e confrontare la velocità di esecuzione tra classi astratte e interfacce.
Copyright Programmazione.it™ 1999-2013. Alcuni diritti riservati. Testata giornalistica iscritta col n. 569 presso il Tribunale di Milano in data 14/10/2002. Pagina generata in 0.263 secondi.