[C#]Dubbi utilità polimorfismo

[RaouL_BennetH]

Buondì a tutti

Ieri sera mentre cercavo di andare avanti con una delle mie applicazioncine, mi sono accorto che due classi che avevo scritto sono praticamente identiche: Hanno lo stesso numero di campi, devono effettuare le stesse identiche cose. L'unica piccola differenza sta nel nome di alcuni campi di queste classi:

//Classe ManutenzioneVeicolo

private int id_manutenzione;
private int id_veicolo;
private string tipoManutenzione;
private DateTime dataManutenzione;
private double importo;
private bool pagato;
private string descrizione;

//Classe ScadenzeVeicolo
private int id_scadenza;
private int id_veicolo;
private string tipoScadenza;
private DateTime dataScadenza;
private double importo;
private bool pagato;
private string descrizione;

//etc...

Come vedete, sono praticamente identiche.
Ho pensato quindi di creare una classe base, far ereditare le due classi da quest'ultima e fare l'override dei metodi vari.

Poi... mi son detto:
Ma forse in questo caso particolare, una 'complicazione' del genere non mi serve, dato che potrei utilizzare un'unica classe per questo scopo.

Ho allargato un pò il ragionamento e mi è venuto un dubbio:

Ovunque ci sia l'applicazione del polimorfismo, se per qualche ragione devo ridisegnare o eliminare la classe base, poi tutto il lavoro fatto sulle altre classi viene gettato al vento ?

Cioè, in questo mio modo rudimentale di creare una classe a se stante per ogni cosa, vedo un vantaggio: se elimino o cambio soltanto la classe che mi interessa, non vado ad impattare su nessun'altra parte del programma.

Qualcuno potrebbe chiarirmi questi dubbi?

Grazie mille

RaouL.

[Kralizek]

Il trucco é sempre quello:
non forzare le relazioni di ereditarietá. Se esiste, é lampante. Se devi cercare una similitudine vuol dire che non lo é: se proprio hai bisogno di un comportamento comune, un'interfaccia potrebbe aiutarti.

[Tommo]

Puoi anche ricorrere ai Component Object e creare un oggetto, che ne so, DatiVeicolo da assegnare poi alle varie classi...
in questo caso ha senso perchè le due classi in se non mi sembra abbiano relazioni ereditarie naturali, ma i dati che contengono si.

[cionci]

Fra le possibili scadenze ci può essere anche una manutenzione ? E quali altri tipi di scadenze ?
Vedo quel private string tipoScadenza; che mi lascia qualche dubbio.

[MarcoGG]

Originariamente inviato da RaouL_BennetH

Ho pensato quindi di creare una classe base, far ereditare le due classi da quest'ultima e fare l'override dei metodi vari.

E costa di più o di meno, anzichè avere due classi distinte anche se simili ?
Avessi 30 classi da derivare capirei...

Originariamente inviato da RaouL_BennetH

Ovunque ci sia l'applicazione del polimorfismo, se per qualche ragione devo ridisegnare o eliminare la classe base, poi tutto il lavoro fatto sulle altre classi viene gettato al vento ?

Tempo fa feci ad un docente una domanda simile alla tua, e mi fu risposto : "Le classi non si modificano mai. Si specializzano." Affermazione un po' "integralista" ( nella vita reale ho sempre visto gente che le classi le modificano eccome ), ma sicuramente fatta da persona che sapeva il fatto suo, ed è anche il caso di questo discorso, credo.
Se elimini la classe base, che bisogno potresti avere delle sue derivate ?
Se già stai ipotizzando di poter eliminare una di quelle classi, mantenendone l'altra la risposta forse è già data : è il caso di tenerle separate.
La classe base dovrebbe sempre essere disegnata in modo tale da non aver bisogno di vere e proprie "modifiche".

Originariamente inviato da RaouL_BennetH

Cioè, in questo mio modo rudimentale di creare una classe a se stante per ogni cosa, vedo un vantaggio: se elimino o cambio soltanto la classe che mi interessa, non vado ad impattare su nessun'altra parte del programma.

Secondo me non è affatto "rudimentale". Molti pensano che se non si usano le caratteristiche più "spinte" di un linguaggio, stanno scrivendo codice "rudimentale"...
Soprattutto se sei nella fase in cui, magari all'inizio della stesura di un progetto, non hai chiaro di quante/quali classi realizzare, stai sul semplice.

[gugoXX]

Originariamente inviato da RaouL_BennetH

Come vedete, sono praticamente identiche.
Ho pensato quindi di creare una classe base, far ereditare le due classi da quest'ultima e fare l'override dei metodi vari.

Il problema secondo me sta qui.
Se devi fare l'override di tutti i metodi perche' le due classi non hanno nulla in comune se non i nomi dei campi, e soprattutto se non hai l'esigenza di centralizzare i processi*, allora il polimorfismo non ti serve.

* Ad esempio il trovarsi a dover gestire una collezione di oggetti base, e di richiamare su ciascuno di essi un metodo che tutti gli oggetti di tale collezione hanno (grazie all'ereditarieta') indipendentemente dal tipo, come per esempio l'estrazione di descrittivi per la visualizzazione in una griglia, lo store in un database, l'aggregazione per qualche calcolo, etc.

[banryu79]

Originariamente inviato da cionci

Fra le possibili scadenze ci può essere anche una manutenzione ?

Che ci dici?

[cionci]

Originariamente inviato da banryu79

Che ci dici?

Smell like teen refactoring

[banryu79]

Originariamente inviato da cionci

Smell like teen refactoring

Sì, io dicevo a Raoul quotando te, perchè ho lo stesso dubbio

[cionci]

Tra l'altro ci sono anche altre cose che puzzano...esiste una classe veicolo ? La classe veicolo mi immagino che abbia il suo id all'interno ed abbia al suo interno anche una lista di scadenze. Allora che ci fa id veicolo nelle altre classi ?

[banryu79]

Originariamente inviato da cionci

Tra l'altro ci sono anche altre cose che puzzano...esiste una classe veicolo ? La classe veicolo mi immagino che abbia il suo id all'interno ed abbia al suo interno anche una lista di scadenze. Allora che ci fa id veicolo nelle altre classi ?

Ho il leggerissimo sospetto che quelle classi non siano altro che la rappresentazione di "Value Object" corrispondenti a tabelle di un database...

[RaouL_BennetH]

Originariamente inviato da banryu79

Ho il leggerissimo sospetto che quelle classi non siano altro che la rappresentazione di "Value Object" corrispondenti a tabelle di un database...

Eccomi

Inizio da banryu79:

Esatto, il database è già esistente, oddio.. database, diciamo 5/6 tabelline

Le classi non servono ad altro che a rappresentare i dati di queste tabelle quindi è come dici tu.

@cionci:
Si, esiste una classe veicolo con il suo id, ma non ha nulla come scadenze o altro. Si limita a esporre i campi contenuti nella relativa tabella del database.

@gugoXX
In questo caso specifico, centralizzare i processi effettivamente non mi occorre.

Di fondo mi pare di capire dalle vostre risposte che se ho un database progettato a cane, di conseguenza qualsiasi cosa ci possa fare io non potrà mai essere veramente decente.

Capisco anche che scrivendo codice sotto una mal progettazione, è evidente che possano venire dubbi anche sui principi cardine della programmazione a oggetti.

[RaouL_BennetH]

Originariamente inviato da cionci

Fra le possibili scadenze ci può essere anche una manutenzione ? E quali altri tipi di scadenze ?
Vedo quel private string tipoScadenza; che mi lascia qualche dubbio.

per entrare più nel dettaglio:

come scadenze sono intese soltanto: bolli, assicurazioni, multe, gps.

per le manutenzioni sono intese invece solo: ordinarie/straordinarie
e nel campo descrizione viene inserito soltanto il testo relativo al numero di fattura di chi ha riparato l'autoveicolo.

[cionci]

Se le classi incapsulano i dati del DB allora non devi fare alcuna gerarchia, se fai una gerarchia nelle classi la devi fare anche nel DB e viceversa, altrimenti non ha senso.

[PGI-Bis]

Originariamente inviato da RaouL_BennetH

Ovunque ci sia l'applicazione del polimorfismo, se per qualche ragione devo ridisegnare o eliminare la classe base, poi tutto il lavoro fatto sulle altre classi viene gettato al vento ?

Cioè, in questo mio modo rudimentale di creare una classe a se stante per ogni cosa, vedo un vantaggio: se elimino o cambio soltanto la classe che mi interessa, non vado ad impattare su nessun'altra parte del programma.

Quanto dici è esatto. Il perchè deriva da uno dei cardini della prospettiva orientata agli oggetti che è il principio di autonomia.

La premessa è che un sistema orientato agli oggetti è fatto di oggetti e contrariamente a quanto si legge in alcuni mirabolanti testi oggetto NON E' ogni cosa.

In un sistema orientato agli oggetti con il termine oggetto si individua una qualsiasi parte autonomamente definibile di un fenomeno. Detto altrimenti una qualsiasi definizione intesa come insieme denominato di predicati è anche la definizione di un oggetto solo se tale definizione non dipende da altre definizioni esistenti nel sistema.

Sebbene la classe in sè non sia un elemento fondamentale dell'orientamento agli oggetti è facile notare come essa rientri pienamente nel concetto di definizione di oggetto in base all'osservazione che essa definisce un modello di comportamento uniforme per un insieme di oggetti: in pratica è una fabbrica di cloni. C'è una definizione di oggetto con la particolarità "meccanica" che da questa definizione può essere usata per produrre un numero infinito di oggetti identici.

Posto che le classi sono definizioni quando una classe deriva da un'altra ciò che succede è che tra la definizione derivata e quella derivante si instaura un rapporto di dipendenza: la definizione derivante richiede che esista la definizione derivata. En passant deve notarsi come la relazione di dipendenza tra definizioni non sia transitiva (questione centrale, se fosse transitiva ogni sistema orientato agli oggetti non potrebbe che essere un sistema composto di un solo oggetto).

Ora se oggetto è tutto ciò che in fenomeno è definibile autonomamente e io mi trovo di fronte a due definizioni A (superclasse) e B (sottoclasse) una delle quali richiede l'altra risulta evidente che A e B sono parti di un solo oggetto.

La superclasse è sempre parte della definizione di un oggetto, qualsiasi intervento sulla parte ha per definizione effetto sul tutto ergo quando cambi qualcosa nella superclasse hai un effetto collaterale.

L'idea della classe a sè stante per ogni cosa corrisponde in linea di principio all'individuazione statica dei diversi oggetti che esistono nel fenomeno.

Da un punto di vista dinamico è necessario tuttavia che gli oggetti "comunichino" tra loro. La comunicazione richiede condivisione di parti della proprio definizione e il punto di equilibrio dell'orientamento agli oggetti sta nella selezione di quelle definizioni che possono essere condivise senza pregiudicare l'esatta rappresentazione di un fenomeno in termini di oggetti, ciò che è reso possibile dalla considerazione che se le definizioni A e B richiedono l'esistenza di una definizione C, A e B risultano comunque reciprocamente indipendenti.

Cioè posso anche dire "ok elimino la classe base e dichiaro due classi separate, magari ripetendo le stesse cose due volte" ma prima o poi qualcuno dovrà "collegarsi" a quelle classi. A un certo punto qualcuno vorrà sapere se la manutezione sia stata pagata. Se per dirlo fa riferimento alla definizione "ManutenzioneVeicolo" allora ManutenzioneVeicolo perderà la propria identità di oggetto in favore della costituizione di un diverso oggetto XYZ + ManutenzioneVeicolo. E' lì che entrano in gioco ereditarietà e composizione: separi la definizione di ManutenzioneVeicolo in due parti (diciamo ManutenzioneVeicolo che estende Manutenzione, giusto per fare un esempio) e così facendo permetti all'oggetto ManutenzioneVeicolo (che è la composizione di due definizioni) di comunicare con un altro oggetto senza perdere la propria autonomia di definizione cioè senza perdere la propria identità nel sistema.