I am building a management tool for recipes. Recipes have a bunch of data, including very generic stuff like an ID, tags, ratings and trivia. I currently only manage recipes, but i want to add support for ingredients, products, etc in the future aswell. These will share the same attributes mentioned above.

Does it make sense to refactor to an inheritance hierarchy early on, or is that a violation of the YAGNI principle?

If it makes sense, are there any good rules on how to set boundaries for superclasses and how to name them? I feel like TaggableRatableTriviaEntity is a pretty bad name.


Let's take a look at your domain:

1) You have Recipes

Recipes are a collection of Ingredients and according steps to follow in order to get things done.

2) Ingredients have a name and perhaps a category (»vegetable«, »spice«, »whatever«)

I see no place where inheritance comes into play.

Does it make sense to refactor to an inheritance hierarchy early on, or is that a violation of the YAGNI principle?

In this case it is not really a violation of YAGNI. But it doesn't make sense. If you want tags on your Recipes, you could put tags in. If you want tags in your Products/Ingredients, put tags in. That's it.

I see at this early point no reason, why a recipe and an ingredient should inherit from something abstract which is taggable and/or rateable.

I would go for the simple solution first. Your goal is to write software, where one is able to collect recipes, invest a minimum of effort to get this done.

Add feature by feature and you will realize when it is time (i.e. »painful« enough) to refactor.

I feel like TaggableRatableTriviaEntity is a pretty bad name.

Yes. It really is. But you should not think in terms of object inheritance, but more in terms of behavioural inheritance - often named interface inheritance. Interfaces only provide behaviour.

Say you are doing Java, you have a class Productwhich implements Rateable and Taggable and inherits only from Base, which provides metadata (who created the item, when was it last modified etc.)

The problem with inheritance hierarchies is, that with increasing levels, the complexity increases.

So do yourself a favour and keep things simple. Leave abstraction out at first and add when needed.

| improve this answer | |

Depending on the language, you don't need an inheritance strategy at all. For example, in Java you would define an interface, in Objective-C you would define a protocol, including all the things that a recipe that you manage would need to be managed, and that other things you might manage in the future would need to be managed.

Any new class that you want to manage doesn't have to be related to a recipe by inheritance, it just has to implement the interface / support the protocol.

| improve this answer | |
  • I really love using interfaces in Java, but the problem is, that i would have to replicate the code in every class implementing it. Adding tags and voting for a rating works the same for every subclass. So i have to put that behavior in an actual class to reuse it. – Luca Fülbier Jul 23 '16 at 13:00
  • The thing i could imagine working out nicely is defining an interface that every class implements (like Taggable and using a TagSet object internally that i delegate the calls to (composition). That would reduce the amount of code duplicated and would provide me with a hook, if the behavior of a specific class changes in the future. – Luca Fülbier Jul 23 '16 at 13:03
  • @LucaFülbier Say you want to rate something: why aren't you simply using an integer variable - say stars - and write a simple setter for it? the only "logic" which would be shared, is simply writing a setter. Done. – Thomas Junk Jul 23 '16 at 14:19
  • Multiple votes are possible, so i have to save the number of votes and the total score, which i can then calculate the average of. Also it will probably get more complicated in the future (changing to different rating systems for example). – Luca Fülbier Jul 23 '16 at 14:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.