Quale alternativa è meglio disegnare questo scenario?

Innanzitutto, i modelli dipendono in larga misura dal dominio aziendale, quindi, dato che l'hai modificato, potrebbe essere che la risposta risponda alla domanda ma non al tuo vero dominio.

1. Dipende da cosa significa la relazione. Un "inventario di società" o "progetti di costruzione attualmente attivi" sarebbero esempi in cui la relazione con AbstractProject sarebbe comprensibile.

2. Lo farei, quindi. Naturalmente, la tua lingua potrebbe renderla difficile e potresti trovare più semplice aggiungere un attributo "tipo" a AbstractProject . (Non va bene perché rompe il principio aperto / chiuso).

   As, outside 1 & 2, penso che Plane e Bridge abbiano così poche cose in comune che probabilmente dovresti saltare del tutto la classe astratta. Ovviamente, questo complicherebbe il modello, dal momento che sai che hai due relazioni con la compagnia (male per il principio open / closed, se finisci di produrre anche Car ), o devi aggiungere un'altra middle class ( ConstructionProject ) , che è quello che vorrei fare.

3. No, non è di alto livello, "libero di cambiare". Sono i dati che passi alle code-scimmie affinché svolgano il loro lavoro, e i dati che passi ad altri team che devono sviluppare SW per usare il tuo sistema, quindi devi seguirlo.

   Questo non ti impedisce di modificarlo se vedi che non si adatta realmente alle tue esigenze, ma quelle modifiche "nel codice" devono essere approvate, riflesse in UML e comunicate. A seconda della filosofia di gestione del progetto, sarebbero interpretati come "errori" o "perfezionamenti" del modello originale.

Se Company non ha bisogno di conoscere la differenza tra Bridge e Plane , il secondo diagramma è effettivamente migliore; codifica il fatto che Company è fondamentalmente ignorante della differenza.

D'altra parte, se Company ha bisogno di comprendere intimamente la differenza tra Bridge e Plane (e qualsiasi altra sottoclasse futura di AbstractConstruction ) allora il primo diagramma è quello giusto; è un modello migliore della natura del dominio. (Potrebbe essere che questa è un'indicazione che il modello è sbagliato in altri modi, come le informazioni di codifica nella classe sbagliata, ma questo è fuori dallo scopo di questa particolare decisione, ea volte è meglio usare una soluzione OO meno perfetta per ottenere un migliore consenso dai partner del progetto.)

Che si adatta meglio al dominio real ? Beh, trovo difficile pensare a una vera compagnia che fa solo Bridge s e Plane s, quindi questo è tutto un sostituto per qualcos'altro (o un esempio di stupido gioco) ed è esaminando i dettagli di quello che capirai più completamente di ciò che dovresti scegliere. Tuttavia, qualunque cosa tu scelga, dovrebbe essere la cosa che meglio modella la situazione reale.

Rinominerei anche AbstractConstruction in ConstructionProject , ma sono solo io. Odio mettere le meta-informazioni in nomi di classe; una classe è astratta se i metadati dicono che lo è, non se ha ottenuto quell'etichetta. E anche il vecchio Construction è sbagliato; è il progetto con cui hai a che fare ...

Questo è quello che farei:

1. Se si desidera tenere presente che non esiste una lista mista, è possibile avere una società con una mappa di elenchi. (tipo di mappatura da elencare)

2. Avendo una mappa di liste come sopra, sarai anche in grado di ottenere il tipo senza dover usare il nome della classe (comunque hai ancora bisogno di qualcosa per l'identificazione degli oggetti). Non sto dicendo che fare questo è meglio. Sto solo dicendo che otterrai ciò che hai detto sopra facendo questo. In effetti puoi anche rinominare AbstractConstruction in ProjectInfo e usare pattern di composizione per averlo all'interno di ogni oggetto Piano o Ponte. Il design è buono dipende dalla situazione e la situazione è essenzialmente ciò che si vorrebbe nell'applicazione (quindi elencare più di ciò che si desidera o ciò che si anticipa che si desidera). Non vedo molto di ciò che vuoi realizzare con un buon design e difendere quel disegno basandomi su ciò che desideri.

3. Personalmente uso diagrammi per assicurarmi di pensare in formato cartaceo prima di codificare un elemento ragionevolmente complesso. Per il punto di progettazione e implementazione, se lo si utilizza come diagramma interno (per sé stessi e il team), non importa se lo si cambia o no. Ma dal momento in cui inizi a distribuire quel diagramma ad altre persone e al team, dovresti assumere che prenderanno decisioni basate sul diagramma quando lavorano sul loro modulo. Qualsiasi modifica apportata dopo avrà effetti a cascata.