Diamo un'occhiata al tuo dominio:
1) Hai ricette
Le ricette sono una raccolta di ingredienti e le fasi da seguire per ottenere risultati.
2) Gli ingredienti hanno un nome e forse una categoria (»verdura«, »spezia«, »qualunque«)
Non vedo alcun luogo in cui l'ereditarietà entri in gioco.
Does it make sense to refactor to an inheritance hierarchy early on, or is that a violation of the YAGNI principle?
In questo caso non è in realtà una violazione di YAGNI. Ma non ha senso. Se vuoi tag sulle tue ricette, puoi inserire i tag. Se vuoi tag nei tuoi prodotti / ingredienti, inserisci i tag. Tutto qui.
A questo punto non vedo alcun motivo, perché una ricetta e un ingrediente dovrebbero ereditare da qualcosa di astratto che è taggable e / o rateable .
Per prima cosa, opterei per la soluzione semplice. Il tuo obiettivo è scrivere software, dove uno è in grado di raccogliere ricette, investire un minimo di sforzo per ottenere questo risultato.
Aggiungi feature per feature e ti renderai conto quando è il momento (cioè "abbastanza doloroso" per il refactoring.
I feel like TaggableRatableTriviaEntity is a pretty bad name.
Sì. È davvero. Ma non si dovrebbe pensare in termini di ereditarietà degli oggetti, ma più in termini di ereditarietà comportamentale - spesso chiamata ereditarietà interfaccia . Le interfacce forniscono solo un comportamento.
Diciamo che stai facendo Java, hai una classe Product che implementa Rateable e Taggable e eredita solo da Base , che fornisce i metadati (chi ha creato l'elemento, quando è stato modificato l'ultima volta ecc.)
Il problema con le gerarchie di ereditarietà è che, con livelli crescenti, la complessità aumenta.
Quindi fai un favore a te stesso e mantieni le cose semplici. Lasciare l'astrazione in un primo momento e aggiungere quando necessario.