Applicazione della composizione sull'ereditarietà alle classi Veicolo

Question

Applicazione della composizione sull'ereditarietà alle classi Veicolo

#1 da (4 voti)
#2 da (2 voti)

4

Ho un programma di manutenzione per auto con una classe Vehicle astratta che ha diverse classi derivate come Car MotorCycle , ecc. Ciascuno di questi veicoli derivati a sua volta è un carburante o un veicolo elettrico. Quindi, invece di avere un FuelCar , ElectricCar , FuelMotorCycle , ElectricMotorCycle ecc., Sto provando a implementarlo usando la composizione.

Il problema ora è che dovrei controllare tutto il tempo se è un veicolo elettrico o di carburante, e quindi fare as cast (è come reinterpret_cast da c ++) di conseguenza, o dovrei avvolgere ogni as cast con% codice%. Aggiunge complessità al codice.

Un'altra opzione stava rimuovendo la classe try catch vuota e ogni veicolo doveva contenere sia EnergySource che Fuel e inizializzarne solo uno nel ctor, ma non sembra giusto avere un'auto a benzina che anche avere una parte elettrica (anche se quella parte è nulla). Anche se questo sembra il più semplice dei tre.

Qualche suggerimento su quale sia l'approccio migliore?

Ecco il diagramma UML di ciò che attualmente ho:

Codice: link

design c# inheritance composition

posta shinzou 07.05.2016 - 16:23

fonte

2 risposte

4

Un'auto ha un Engine e Fuel sia a combustione che elettrica. Sono le tue classi base abstract . Quindi, una vettura ha un Engine e non dovrebbe importare se quel motore è un CombustionEngine o un ElectricEngine .

risposta data 07.05.2016 - 16:57

fonte

Leggi altre domande sui tag design c# inheritance composition

Il blocco di un'interfaccia utente a volte è una buona idea? Come segnalare un ciclo per continuare l'esecuzione invece di usare il sonno

score 2 · Accepted Answer

@radarbob those members are specified, I didn't choose them.

Le mie simpatie.

... Hybrid cars shouldn't be allowed and are irrelevant.

Ok. Quindi è meglio non avere entrambe le proprietà Fuel e Electric in Vehicle . "Invia il messaggio sbagliato"

... I don't see how placing properties in interfaces help here, I'm still in square one.

Nell'universo di StackExchange vedo l'eccessivo utilizzo di interface s (il tipo di parola chiave). Penso che sia una esuberante mis-application e incomprensione di "code to interfaces not implementation."

... Lastly, you mean a solid rhombus en.wikipedia.org/wiki/Class_diagram#Relationships

Jessica Simpson su UML

... Anything else you would like to add?

Sì.

Avvolgi un Vehicle in una classe VehicleEnergy

Dato il progetto come mostrato, passa un'istanza Vehicle in una classe VehicleEnergy con metodi o proprietà wrapper appropriati per interrogare il tipo di veicolo EnergySource che è. Ma non vedo come tu possa aggirare il fatto che da qualche parte, in qualche modo devi interrogare l'oggetto.

Questo sembra un buon compromesso tra le preoccupazioni. Mi chiedo se il turbinio di commenti su questo thread sia il risultato di - un sintomo di - preoccupazioni contrastanti.

Penso che questo design ibrido (gioco di parole) esprima gli aspetti separati e quindi esprima la loro interazione in un'interfaccia coerente (il tipo senza parole chiave).

L'oggetto Vehicle può sempre essere usato così com'è o camuffarsi, per così dire.

Oh, sì ... Potrei usare il modello di fabbrica e passare un enum per il veicolo desiderato. Non ci sarà alcun enum member per un veicolo ibrido, quindi questo diventa un modo strongmente tipizzato di comunicare che "ibrido" non è definito.