Multiple Instances of a concrete class vs multiple implementations of an abstract class

Question

I need to design a vending machine that dispenses various drinks like tea and coffee.

I am almost done with the design, but there is this one decision that I am not able to take.

About the Drink class.

Should I make a concrete Drink Class with certain attributes and for every drink make a new instance and set the attributes accordingly.

Example:-

Drink tea = new Drink();
Drink coffee = new Drink();

or Another approach can be that I make an abstract Drink class.

abstract class Drink{ }

and make tea and coffee like

class Tea extends Drink{ }
class Coffee extends Drink { }

What are the pros and cons of both the approaches?

Answer 1

It depends, and one of the approaches is not always better than the other approach.

An advantage of having subclasses per type of drink is that you can implement functionality that is specific for the type of drink in the appropriate subclass, instead of having to put all functionality for all kinds of drinks in the Drink class. But whether this is relevant to your application depends on what exactly the role of a Drink is, and whether you need drink type specific functionality.

If class Drink is just a simple data container class, for example it holds a few fields for the name of the drink etc. and you don't need specific logic for different kinds of drinks, then the first solution is simpler, you'd only need one class Drink.

Answer 2

Go with the Abstract approach. It offers the advantages of Code Reuse and Polymorphism . And I am sure you have heard the term "Always program to the interface". This is your chance to apply it.

Answer 3

If only the fields differ from one instance to another, I would recommend you the first approach, if the behavior (the methods) can also differ, I would recommend the latter.

Another point to consider is if you want to be able to add new kinds of drinks without upgrading the application...

Answer 4

You don't have to model a Drink for any general purpose, you only need to keep track of a few things such as

• name (which drink is this?)
• inventory (how many of these drinks remain available)
• price (per unit)
• sales (a registry of units sold by date)
• code (so to know which drink has been selected)

There might be some more (image?), but you don't need your drinks to know specific properties that make sense in some cases and not in others (e.g., color for red/white wine). For instance, you could easily distinguish between sparkling and still water by having two different instances of the same class and in fact having a Water class would be overkilling because it would add nothing interesting to your model.

In other words, model your objects in relation with the context of your project and resist the temptation to model all the properties and behaviors you can think of but that are not relevant in your specific domain.