Interface explanation

For me, interfaces are a way to standardize classes available to the programmer in a way that makes parts behave together, while avoiding the dreaded spaghetti code.

So, I guess interfaces are like a menu? The customer (class calling the interface) takes their requested spaghetti (class being called) from the chain restaurant, who is using the same menu (interface) as a way to standardize the requests they receive from each customer across the franchise

To rephrase, just like interfaces are a contract between a “calling” and a “worker” class, a menu is a contract between a customer and a chain restaurant that lets each “calling” class / customer confidently request the same thing each time from the “worker” class / restaurant, no matter where the CheeseBurger() is called / ordered from.

1 Like

Yes.

Interfaces don’t really help with that.

If I’m getting what you mean, yeah kinda but not really.

Using the menu metaphore, it’s more like using the Menu Item Interface, perhaps called IMenuItem and they could have a OrderItem(), MakeItem(), GetItemPrice(), GetImage(), GetIngredients() and so on where the cheeseburger implements IMenuItem.

This would (in theory) allow the cash register to also use IMenuItem to handle the ordering of multiple for customers and then at the same time, could allow the inventory system to keep track of stock and even order IMenuItems from suppliers. Perhaps even hook up to a delivery service without any of the systems needing to specifically know what a cheeseburger, fries, coke or even an icecream is.

So to get back to your example on why not really, the Interface would actually allow each restaurant to deliver a different CheeseBurger() in each restaurant, but it would allow each Worker class to not need to know what a CheeseBurger is. It could allow the customer to order a CheeseBurger() the same way in each place, but since you’re using an Interface, each implementation of MakeItem() could be different.

Clear as mud, right?

2 Likes

Privacy & Terms