I am practicing design patterns and OO concepts such as inheritance in java and I'm writing an application that represents a vending machine.
I have two questions focused on ideal structure and design patterns:
- What is an alternative way to decide which treat from the vending machine to manufacture based on the passed name parameter of the treat object(see below there are three treat type classes derived from a treat superclass). I am currently using switch statements and conditional statements based on treat name.
- What is the best way to represent a list of potential variables for "brand name" of the treat. The brand names can be used by a salty treat or a sweet treat, but not by the healthy treat.
So I have a vending machine class that has a "treat" class that represents a superclass for all treats held within the machine.
The treat class has three types of objects that inherit from treat: "salty", "sweet", "healthy."
Each of these types of objects will then have specific methods (like getIngredients()) and member variables (name, price) that are unique to those objects.
But I'd like to have a class that is merely a list of the brand names that can be a member variable of the salty and sweet treat objects. Healthy is different because it won't have a brand -- it will just be fruit.
For example, the Nabisco brand could be a member variable of two of the three treat types: "Oreos" (sweet), "Wheat thins" (salty).
Should I maybe use a command pattern to determine which treat to generate based on the name? I'd just like to avoid switch/conditionals if possible and use the best design patterns for each task. I've watched videos and have been reading tutorials on how to use patterns but I'm still unsure in these two cases which is best to use. I also can't find a good example on stack exchange that deals with my issue there.
Should I try to use a strategy pattern to store this list of brands that has no other function but is simply an attribute stored within an object? Something like BrandStrategy --> assignBrand() --should brand even be stored in it's own class? It seems like it should since two subclasses would use it.
Diagram of Program:
VendingMachine
|
FactoryMethod (Creates treat based on treat "name")
|
Treat (Abstract class)
/ | \
Sweet Salty Healthy (Concrete classes: inherit from treat)
^ ^
| |
Brand class (member variable of sweet & salty)
I have been reading about design patterns and best practices and I've been trying to avoid switch statements and conditional statements to generate specific objects and I've been reading that poor use of enums can create brittle code. I originally had "brand" stored as an enum but I'm realizing now that is a bad way to do it since that value is likely to change (basing this statement off of this post I researched).
Here are some of the stack exchange posts and tutorials I have read:
- https://stackoverflow.com/questions/61024826/what-is-the-best-way-to-structure-a-group-of-variables-that-have-a-group-of-vari
- Refactoring Switch Statements and is there any real use for Switch Statements at all?
- https://www.planetgeek.ch/2009/07/01/enums-are-evil/
- https://stackoverflow.com/questions/4417070/switch-statements-are-bad
- https://www.javatpoint.com/design-patterns-in-java
- https://stackoverflow.com/questions/38855909/alternative-to-enum-in-design-pattern
if
,switch
or equivalent constructs. You can hide them, but you can't get rid of them. Wrapping them into a Factory is a good idea, but that doesn't change the fact that you need anif
.enum
is indeed a bad idea, but implementing them as sister classes is almost as bad. You really should try to find a solution that doesn't require recompiling when a brand is added. Depending on how you factor things, the brand might be nothing more than a string-typed label, while the business-relevant aspects between brands are represented by classes that implement that aspect, not a brand that happens to have it.