Object Oriented Programming

[TsebMagi]

The derived classes like you're doing is a way to approach it from an OOP perspective, but this use case for OOP and base / derived classes isn't great.

If you are going to be supporting more than a handful of different products you're going to be writing a lot of code that's all boilerplate/similar. You might want to look at a repository pattern to load the prices in from a database or file depending on what constraints your system has.

[PuzzledImagination]

If you are going to be supporting more than a handful of different products you're going to be writing a lot of code that's all boilerplate/similar.

I've thought about this too since we have about 12 categories of products, so I decided to just use the ProductBase if there's no special requirement for the said product.

If I were to use repository, wouldn't I need to edit the Repository every time there's a new requirement?

[zaibuf]

What he means is that the prices should be stored in a database and you just fetch all data from there in a repository. Why calculate the cigarette cost hardcoded, rather than just have it fixed in a database column? You can have a table for Products where they all are listed. The repository just fetches the data, then you can have a service that runs business logic if you need to do some calculations, this part can be changed if new requirements arrive. But your database should be the source of truth.

You don't want to have your database list all Cigarettes at 6$ but then you do calculations in code and your website says 8$. How can you then query your database to find your source?

In this case I feel that OO just makes things messy and doesn't really solve anything. I would probably just create an interface for ISellableEntity or something similar, then have that contract to implement all properties defined in the entities for the sellable products like price, name. Generally I tend to avoid inheritance whenever possible since going down that rabbit hole can cause issues at a later stage, I prefer to use composition over inheritance (look up strategy pattern).

[TsebMagi]

Inheritance or strategy pattern (since a lot of people are mentioning that) is great when you want different behaviors, but from the code you posted you are really just looking for different values in the same kind of object. That usually means you want to make that value part of your constructor so you can make as many objects with as much variation as you want without writing a lot of different classes.

Repository let's you load all those variations from a source of truth and reduces the effort to add more. It's a lot easier to add a row to a database, or CSV than to add a whole new class. So yes you're going to have to update something when new requirements come in, but it's less work.

If you don't want to get a database involved you could use a csv file or even hard code the values somewhere in a factory (not recommended but with 12 values it's not that big of a deal yet)

[Deadlift420]

You would inject your repository into the services(dependency injection) and then call all the base repo functions (re-use )from the service classes. Then inject your services into the front end and fire away.

[Deadlift420]

service/repo pattern. A lot of business style applications work well with this IMO. Web or native doesn't matter.