UML Class Diagram: Abstract o Interface?

Devi creare una classe astratta.

In generale, una canzone può essere composta da un titolo / artista / album / genere. Tutti questi sono solo una stringa di dati che può essere gestita allo stesso modo. Usando una classe astratta non devi scrivere "getName", "setName" e "getCount" più di una volta, il che sembra molto carino.

L'utilizzo di un'interfaccia ti dirà solo che le funzioni dovrebbero esistere in ogni classe, ma dovrai comunque scriverle separatamente. Tuttavia, se si presentano metodi che hanno tutti in comune, ma che funzionano in modo diverso per ogni classe, suppongo che un'interfaccia abbia più senso.

Ciò che mi infastidisce è che vuoi che siano classi. Ad esempio, poiché vorresti che un album avesse il suo "Times played", dovresti assicurarti che ci sia una sola istanza di quel specifico album. Ogni volta che viene aggiunto un nuovo brano, devi cercare tra tutte le classi esistenti con quel nome e impostare un puntatore o qualcosa di simile a quello già esistente.

Inoltre, la parte migliore dell'utilizzo di un album come istanza di una classe è che è possibile avere diversi album con lo stesso "nome" senza contarli come lo stesso album. Err ... comunque, la mia mente si è allontanata e questo non è realmente correlato alla domanda.

Vorrei usare invece le interfacce. Dalla mia esperienza, ci sono 2 ragioni per questo:

• Usa la classe (astratta) solo alla radice del diagramma quando sei così sicuro che le sottoclassi sono molto simili
• A meno che tu non sia molto fluente nell'area, dovrai apportare molte modifiche non solo al tuo codice ma anche al tuo design. Questo è quando le interfacce saranno molto più adatte, cambiando attorno all'intero albero di ereditarietà è molto meno dirompente che affrontare le classi astratte.

Pensa al diagramma di Venn e a due insiemi di funzionalità non uguali. A e B. In java puoi estendere solo una classe astratta, quale dovresti scegliere? Se scegli A, un po 'di tempo in futuro, sorge il bisogno che non hai previsto in modo che B si gonfia per essere più grande di A. Devi passare a B e poi qualcosa che non hai previsto sorge e cambi di nuovo ad A.

È meglio usare semplicemente le interfacce e quando il codice base è stabile, si refactoring e si comunicano le stesse funzionalità in una classe astratta. Le interfacce sono molto più agili e adatte a quei cambiamenti costanti. Certo, se già conosci fin troppo bene ciò che verrà anticipato, allora vai con tutte le classi astratte.