Design Patterns with database usage
database, design-patterns, oop
Solution
...and in real life all these pizzas and stores are just rows in database.
Does database check for invariants, business specifications or some other custom rules provided by your classes (in oop term)? No. Databases are simply a storage for most applications.
Those rows are the result of a smart and reliable computation from your domain model and business logics. Design patterns may help you to build a flexible code that could cover all those business rules.
we know that is impracticable to create a class for each product
Design patterns merely bring some abstraction on behavior specializations and don't care about strict nature of data. Indeed, if a `ChicagoPizza` class is created, this is to specify some unique specialization, not for simply marking: "this pizza is a Chicago one".
I don't know many applications that deal with more than dozens objects related to the same theme, all having some strong and distinct specializations.
In case of creational patterns (as you mentioned), I'd say that if you have so many "objects" that differ only by their "nature", you should just end up with a simple kind of `type` attribute (on the base class) mapped in database rather than using extra subclasses in this case.
I don't find a gap at all between what is mentioned on programming books and the software reality.
Your domain model (hard-coded by definition) should almost always be favored over database thinking.
In conclusion:
I know they are all examples, but I think that is painful after you learn from a book
If "example" means distinct from reality, then they are not examples at all. They are just a mini portion of a real software that could be made.
Problem
I see 99% of Design Patterns examples (Strategy, Factories, Decorator, etc..) with hard-coded information, each product in different classes, etc.. but, in most real life applications, mainly with database usage, we know that is impracticable to create a class for each product, or work with hard-coded information. I know they are all examples, but I think that is painful after you learn from a book: Create classes for CheesePizza, VeggiePizza..and classes for stores NYStore, ChicagoStore for Factory Pattern.. and in real life all these pizzas and stores are just rows in database. So, what's the best approach to work with database and design patterns in this case? - If pizzas and stores are in database, don't need to use Design Patterns. - Use design patterns, but instead creating a class per Pizza or Store, just create a single class implementation that read data from database (eg. DatabasePizza and DatabaseStore!). I understand the importance of Design Patterns with payment business for eg. (Cash, Credit Card, Bitcoin..) where each one payment type have unique specializations and the business isn't fully in database (credit card needs to print receipt, bitcoin to access webservice, etc). But what I'm questioning is: in a real Pizza Restaurant where prices, ingredients, toppings, all according with different places (Chicago, NY..) are located in database, the usage of Design Patterns is really necessary? The usage of Design Patterns naturally decreases when a lot of business are located at database?