Diagramma UML per attributi che possono avere due tipi diversi

1

Sono stato a un'intervista per un lavoro di programmazione finanziaria, e non ho potuto rispondere ad una domanda di sicuro. Ci ho pensato di nuovo, ma non riesco davvero a trovare una buona risposta.

Mi hanno chiesto di progettare il diagramma UML per uno strumento di classe (strumento finanziario, come obbligazioni o azioni), che ha un prezzo, un tipo che può essere solo "Forex" o "Tasso", e un nozionale che può o essere un doppio o doppio + array di oggetti.

Il prezzo non è un problema, è solo un doppio.

Ma sono bloccato sul tipo: ho pensato a un enum ea un booleano, ma non sono sicuro che sia il modo migliore per farlo

e sul nozionale: ho progettato un'altra classe per questo, con un doppio attributo e una matrice opzionale di attributo dell'oggetto. Ma anche questo è davvero brutto.

Quale sarebbe il modo migliore per risolvere questo problema?

Grazie per il tuo aiuto

    
posta MarinD 19.05.2015 - 15:53
fonte

1 risposta

2

La presenza di un attributo type è un po 'preoccupante per me. Il fatto che possano esistere diversi tipi di strumenti implica che ci debba essere un'interfaccia Instrument astratta, con metodi comuni dichiarati e molteplici implementazioni concrete (azioni, obbligazioni, ecc.). Il forex / tipo di tasso può rientrare in questa categoria, oppure no. Non ne so abbastanza degli strumenti finanziari per fare una buona scelta qui. Forse la domanda stava davvero chiedendo di chiedere di più sul dominio?

In generale, dare degli attributi di tipo oggetti è qualcosa che cerco di evitare. Se li inserisci, probabilmente avrai un codice al di fuori della classe che si comporta in modo diverso a seconda del tipo di oggetto utilizzato. Ciò viola l'idea che in OOD si lasci che l'oggetto faccia il lavoro (passando tutte le informazioni extra necessarie), non il codice che usa l'oggetto. In altre parole, gli attributi di tipo annullano lo scopo del polimorfismo. In ogni caso, il compilatore di solito fornisce informazioni sul tipo automaticamente per tutti gli oggetti. Puoi usare quello?

A volte gli attributi del tipo hanno senso, per esempio se vuoi raccogliere alcune statistiche su una collezione di oggetti polimorfici (20% di azioni, 35% di obbligazioni, 40% di forex, 10% di tasso, ecc.).

Non sapendo molto su cosa sia un "nozionale", penso che la tua soluzione per avere una classe con un array doppio e opzionale sia una scelta ragionevole. Non vedo alcuna ragione per cui il caso degenerato di un grafico con un array vuoto sia meno valido di uno con un array non vuoto.

Se devi assolutamente avere un attributo type per forex e rate, andrei con un enum. Primo, solo perché può essere solo una delle due cose ora non significa che più cose non saranno necessarie in seguito (per quanto riguarda opzioni, derivati, credit default swap, ecc.?). Secondo, se vai con un booleano, dove vero significa tasso forex e falso, allora stai implicitamente dicendo che uno strumento che è "non forex" è uno strumento di velocità. Non è esattamente la stessa cosa che dire esplicitamente che uno strumento è uno strumento di valutazione. Combinando "non forex" e vota, previeni che i concetti siano separati in futuro.

La conclusione che sto arrivando è che la classe di strumenti generali dovrebbe essere debole. C'è così tanta variazione nelle specializzazioni che ha poco senso spingere molte funzionalità e attributi nella superclasse. È un po 'come mettere auto, aerei, barche e treni in una classe di veicoli. Non c'è molto che puoi mettere lì oltre a portare capacità e peso, e il fatto che le istanze di ciascuno sono tutte Veicoli. Meglio lasciare che i singoli tipi di strumenti si trovino da soli, raccolti in modo approssimativo nella classe Instrument.

    
risposta data 19.05.2015 - 22:08
fonte

Leggi altre domande sui tag