OOP. Choosing objects

Question

I'm a relative newbie to thinking in OOP terms, and haven't yet found my ‘gut instinct’ as to the right way to do it. As an exercise I'm trying to figure out where you'd create the line between different types of objects, using the drinks on my desk as an example.

Assuming I create an object Drink, that has attributes like volume and temperature, and methods like pour() and drink(), I'm struggling to see where specific drink 'types' come in.

Say I have a drink types of Tea, Coffee or Juice, my first instinct is to sub-class Drink as they have attributes and methods in common.

The problem then becomes both Tea and Coffee have attributes like sugars and milk, but Juice doesn't, whereas all three have a variant (Earl Grey, decaff and orange respectively).

Similarly, Tea and Coffee have an addSugar() method, whereas that makes no sense for a Juice object.

So does that mean the super-class should have those attributes and methods, even if all the sub-classes don't need them, or do I define them on the sub-classes, especially for attributes like variant, where each sub-class has it's own list of valid values?

But then I end up with two addSugar() methods, on the Tea and Coffee sub-classes.

Or given that I then end up putting all the attributes and methods on the super-class, as most are shared between at least a couple of the drink types, I wonder what was the point in sub-classing at all?

I fear I am just trying to abstract too much, but don't want to back myself in to a corner should I want to add a new type, such as Water—with variant still or sparkling—down the road.

Answer 1

Part of the problem is that real-world objects aren't neatly arranged in a hierarchy. Every object has many different parents. A glass of juice is certainly a drink, but it is also a source of nutrition -- but not every drink is. There's not much nutrition in a glass of water. Likewise, there are many sources of nutrition which are not drinks. But most languages will only let you inherit from one class. A cup of tea is technically a source of energy (it is hot, it contains thermal energy), but so is a battery. Do they have a common base class?

And of course, the bonus question, what's to prevent me from putting sugar in my juice if I want to? Physically, that is possible. But it is not conventionally done. Which do you wish to model?

Ultimately, don't try to model "the world". Model your problem instead. How do you want your application to deal with a cup of tea? What is the role of a cup of tea in your application? Which, if any, of the many possible parents makes sense in your case?

If your application needs to distinguish between "drinks you may add sugar to" and "drinks you can only consume untouched", then you would probably have those be two different base classes. Do you even need the common "drink" class? Perhaps, perhaps not. A bar might not care that it is a drink, that it is drinkable. it is a product that can be sold, and in one case, you must ask the customer if he wants sugar in it, and in the other case that is not necessary. But the "drink" base class might not be necessary.

But for the person drinking the drink, you probably want to have a "Drink" base class with a Consume() method, because that is the important aspect of it.

Ultimately, remember that your goal is to write a functioning program, and not to write the perfect OOP class diagram. The question is not "how can I represent different types of drinks in OOP", but "how can I enable my program to deal with different types of drinks". The answer might be to arrange them in a class hierarchy with a common Drink base class. But it might also be something else entirely. It might be "treat all drinks the same, and just switch the name", in which case one class is plenty. Or it might be to treat drinks as just another kind of consumable, or just another kind of liquid, without actually modelling their "drinkable" property.

If you're writing a physics simulator, then perhaps a battery and a cup of tea should derive from the same base class, since the property that is relevant to you is that both are able to store energy. And now juice and tea suddenly have nothing in common. They might both be drinks in another world, but in your application? They're completely distinct. (And please, no nitpicking about how juice contains energy too. I'd have said a glass of water, but then someone would probably bring up fusion power or something ;))

Never lose sight of your objective. Why do you need to model drinks in your program?