How about Dishes are the same, but the Menu takes two arguments. If it is displayed completely differently, then yes. There is nothing else, at least you mentioned nothing else.Ībout design 2: Would a typed MainDish make sense? Since in OO objects are defined by their behavior, would a MainDish behave differently than a NormalDish? Depends on the exact requirements. What behavior would a Dish have? Well, if you would formulate your requirements a little bit better, it would be clear that a Dish just displays itself. Records do not exist in OO.Īgain, this ties into your question. Having "objects" that only hold data is diametrically opposed to this concept. Etc.Ībout design 1: Object orientation is about behavior, while encapsulating (hiding) data. You could say: We want to display the main dish on a website. Again, this is not nitpicking, this is absolutely important for deciding about interfaces. Dishes having a name and a list of ingredients is completely irrelevant, unless you use it in a context of a functionality. I kind-of suspect what you imply, but requirements are about functionality. They just compound in a way that makes simple answers impossible, so bear with me please. There are multiple small-ish issues I have with your question.
INTERFACE SEGREGATION PRINCIPLE PYTHON CODE
Also it seems a little bit weird to me to have to check the type of the class, because that is usually a code smell in OOP. Just to clarify, I see the point of ISP, but I'm not sure that it's applicable here because being the main dish is something arbitrary defined by the customer. I want to fully understand why that approach would be better in the long run. Is this correct? Does this offer any advantages? I think Design 1 is better because it is simpler, but other members of the team suggest Design 2. Then the Menu object would be more or less the same, but checking the type of the dish instead of one of its attributes: class Menu:ĭef _init_(self, dishes: List): Using the Interface Segregation Principle, someone may suggest the following approach: from abc import ABC Raise ValueError("You must provide one main dish") This has, among others, the following implications for the consumer of this class, let's say, a Menu class: class Menu:
In this approach, we represent the main dish requirement as a field inside our object. Let's suppose we are using an OOP approach, and we have two possible designs (I'm using python but it should not be relevant): Design 1 class Dish: The restaurant owner always wants to have a dish (and only one) marked as the "main" dish. They have a name and a list of ingredients. Let's say we have the following business requirements:
0 kommentar(er)
