OOD: tutte le classi nella parte inferiore della gerarchia contengono lo stesso campo

Naviga le tue risposte
1

Sto creando un diagramma di classe per quello che pensavo fosse un problema abbastanza semplice. Tuttavia, quando arrivo alla fine della gerarchia, tutte le classi contengono solo un campo ed è lo stesso.

Questo aspetto mi sembra molto sbagliato, ma questo campo non appartiene a nessuna delle classi genitore. Mi stavo chiedendo se ci sono degli schemi di progettazione suggeriti in una situazione come questa?

Di seguito è riportata una versione semplificata del diagramma delle classi.

Nota, i campi con nomi diversi non possono appartenere a nessun'altra classe 

                        +------------------+
                        |   NoteMapping    |
                        |------------------|
                        | String noteId    |
                        | String content   |
                        |                  |
                        +---------+--------+
                                  |
                  +---------------+----------------+
                  |                                |
         +--------|--------+              +--------|--------+
         |     UserNote    |              |    AdminNote    |
         |-----------------|              |-----------------|
         | String userId   |              | String adminId  |
         |                 |              |                 |
         +--------+--------+              +--------+--------+
                  |                                |
                  |                                |
         +--------|--------+              +--------|--------+
         |  UserBookNote   |              |  AdminBookNote  |
         |-----------------|              |-----------------|
         | String bookId   |              | String bookId   |
         |                 |              |                 |
         +-----------------+              +-----------------+

Tabelle ASCII disegnate usando link

Modifica

Ho aggiunto alcuni nomi di classi e campi al diagramma delle classi sopra.

Il motivo bookId non può esistere in nessuna delle classi genitore è perché è usato per creare una relazione OneToOne con un'altra classe - che non è qualcosa che vogliamo sempre fare.

    
posta My Head Hurts 30.11.2012 - 17:15
fonte

3 risposte

3

Lo scenario che hai descritto probabilmente significa che esiste un elemento (il campo di cui ti stai preoccupando) che effettivamente proviene da una gerarchia diversa. Questo sembra essere il tipico caso d'uso per l'ereditarietà multipla, come già detto in un commento di jwernerny.

Pensa a questo: tutte le auto esistenti derivano (ereditate) da una "macchina" astratta di qualche tipo. Puoi disegnare un albero che li collega tutti (un albero genealogico). In quale punto dell'albero genealogico metteresti il navigatore GPS che puoi vedere all'interno di ogni auto moderna?

Molto probabilmente, si finirebbe con un campo chiamato "navigatore GPS" in ciascuna delle ultime (più moderne) classi del tuo albero. Ciò accade perché il navigatore GPS proviene da un mondo diverso (l'elettronica) e non ha nulla da condividere con le automobili.

Questa è la tua situazione?

    
risposta data 30.11.2012 - 18:53
fonte
0

Metterei solo la stringa cinque in ObjectAA o ObjectAB o anche in ObjectA, quindi accetti solo che rimarrà vuoto o nullo per la maggior parte del tempo. Potrei non farlo se sospettassi che ObjectAAA e ObjectABA stiano per essere migliorati in futuro, o se davvero rendessero la logica molto più facile da seguire. Immagino che la linea di fondo sia, in che modo è più facile da capire?

Ci sono davvero tre modi in cui una classe si distingue dagli altri.

Potrebbero avere diversi dati in esso contenuti, che è praticamente quello di cui stiamo discutendo qui.

Oppure i suoi metodi potrebbero fare cose diverse: stesso nome, ma codice diverso. Se questo si applica qui, non mi preoccuperei dei campi duplicati. Dovresti usare classi diverse se fanno cose diverse anche se non contengono nuovi campi.

O potrebbe solo significare qualcosa di diverso dal programmatore. Di solito è una funzione di campi, metodi e intenti futuri. Se ha più senso, vai con esso. (Ma se due classi sono identiche nei campi e nei metodi - o anche nelle vicinanze - potresti chiederti se i due concetti diversi dietro di loro sono in realtà la stessa cosa.)

    
risposta data 30.11.2012 - 17:34
fonte
0

A volte la duplicazione del codice è un buon approccio pratico.

L'ho scritto davvero? Non spararmi ora, ascolta prima.

Come affermato più volte: senza un caso concreto è difficile dirlo, ma a volte è più facile vivere con le conseguenze di una piccola duplicazione. Quando si tratta di un caso speciale, lo sviluppatore C ++ urla: ereditarietà multipla , mentre gli appassionati di Java canticciano Generici . Dico KIS - mantieni la semplicità . Non troppo semplice, cioè non più semplice del problema in sé, ma nemmeno più complesso! IMO ottieni più benefici da strutture chiare che da un sistema generico che può coprire tutto (a costi di leggibilità).

    
risposta data 30.11.2012 - 21:58
fonte

Leggi altre domande sui tag

Mingling transazioni DB e registrazione da una prospettiva di progettazione Specifiche dei requisiti con annotazioni? [chiuso]