Wag*_*rdi 5 database oop design-patterns
我看到99%的设计模式示例(策略,工厂,装饰器等)具有硬编码信息,每个产品在不同的类中等等.但是,在大多数现实应用中,主要是数据库使用,我们知道为每个产品创建一个类,或使用硬编码信息是不切实际的.
我知道它们都是例子,但我认为从一本书中学到以后这很痛苦:
为店铺NYStore,ChicagoStore创建CheesePizza,VeggiePizza ...和类的课程
对于工厂模式..而在现实生活中,所有这些比萨饼和商店只是数据库中的行.
那么,在这种情况下,使用数据库和设计模式的最佳方法是什么？
我理解设计模式与支付业务的重要性,例如.(现金,信用卡,比特币..)每种支付类型都有独特的专业化,而且业务不完全在数据库中(信用卡需要打印收据,比特币需要访问网络服务等).
但我正在质疑的是:在真正的比萨餐厅,价格,配料,配料,所有根据不同的地方(芝加哥,纽约..)都位于数据库中,设计模式的使用是否真的有必要？当许多企业位于数据库时,设计模式的使用自然会减少？
...在现实生活中，所有这些披萨和商店都只是数据库中的行。
数据库是否检查您的类（在 oop 术语中）提供的不变量、业务规范或其他一些自定义规则？不。数据库只是大多数应用程序的存储。
这些行是根据域模型和业务逻辑进行智能且可靠的计算的结果。
设计模式可以帮助您构建可以涵盖所有这些业务规则的灵活代码。
我们知道为每个产品创建一个类是不切实际的
设计模式仅仅带来一些行为专业化的抽象，并不关心数据的严格性质。
事实上，如果ChicagoPizza创建一个类，这是为了指定一些独特的专业化，而不是简单地标记：“这个披萨是芝加哥披萨”。
我不知道有多少应用程序可以处理与同一主题相关的数十个以上的对象，并且所有对象都有一些强大且独特的专业化。
在创建模式的情况下（正如您所提到的），我想说，如果您有这么多仅因“性质”而不同的“对象”，那么您应该最终得到一种简单的属性type（在基类上）在这种情况下，映射到数据库中而不是使用额外的子类。
我没有发现编程书籍中提到的内容与软件现实之间存在任何差距。
您的领域模型（根据定义是硬编码的）几乎总是应该比数据库思维更受青睐。
综上所述：
我知道都是例子，但是我觉得从书本上学到之后会很痛苦
如果“例子”意味着与现实不同，那么它们就根本不是例子。
它们只是可以制作的真实软件的一小部分。