È codicile avere classi vuote nel mezzo di una gerarchia di classi?

Question

A volte mi ritrovo con una gerarchia di classi in cui ho una classe base astratta con alcune funzionalità comuni e un paio di classi di implementazione che rientrano in due (raramente più) gruppi che voglio trattare in modo diverso in alcuni casi. Un esempio potrebbe essere una classe di nodo dell'albero astratto e diverse implementazioni di rami e foglie in cui voglio distinguere rami e foglie in qualche punto.

Queste classi intermedie vengono quindi utilizzate solo per le istruzioni "is-a" nel controllo di flusso e non contengono alcun codice, anche se ho avuto casi in cui hanno "sviluppato" del codice in un secondo momento.

Ti sembra maleodorante? Nell'esempio del mio albero, un'alternativa sarebbe quella di aggiungere /isBranch() metodi astratti alla classe base e implementare quelli nelle classi intermedie, ma non sembrava che fosse meglio per me, davvero, a meno che non intendessi avere classi che potrebbero essere più cose contemporaneamente.

Answer 1

In generale, classi vuote sono un odore di codice.

Sono d'accordo che i tuoi metodi isLeaf o isBranch sono un'alternativa corretta. Essi aggiungono informazioni sugli oggetti, che è utile. (Questo perché, in super classe, non è possibile esprimere che le sottoclassi sono "o foglia o ramo").

---

I due metodi con risultati opposti potrebbe anche essere considerato come duplicazione del codice.

Si potrebbe usare solo uno ... Ma io consiglio di restituire un valore numerato LEAF o BRANCH.

Answer 2

Sì, le gerarchie di ereditarietà profonda sono un odore di codice in ogni caso.

Answer 3

Una classe che non contiene alcun codice è sicuramente un codice-odore ....

Answer 4

Per me, l'uso di test "is-a" nel controllo del flusso è altrettanto puzzolente quanto l'uso di switch/case. In un buon design OO, nessuno dei due è necessario.

Answer 5

Sì, sicuramente un odore di codice: non codificare queste classi vuote a meno che non siate pronti a scrivere quel codice. Pensa a YAGNI (non ne avrai bisogno) - non farlo se non ne hai già bisogno.

Inoltre, avete considerato casi in cui queste classi sono solo lì per fornire metodi astratti, o per raggrupparli in base alle capacità in termini di metodi o proprietà?

Se è questo il caso, forse ciò di cui hai veramente bisogno sono le interfacce, non altre classi astratte?

Answer 6

Sembra giusto per me, se hai intenzione di inserire nuove funzionalità in seguito.

In caso contrario, un enumerazione viene generalmente utilizzata qui.

- Modifica

Anche se devo concordare con Ber, che non si dovrebbe in genere utilizzare 'è-un' comunque.