Java 面向对象的购物车设计模式

我试图学习oo设计模式，并开发购物车应用程序，不同的购物车项目将有不同的类型。每个类型都有一些附加属性

选项1：创建一个单独的类，每个购物车项目在基类中都有自己的属性和公共属性，这是否好。在这个选项中，我必须在数据库中创建多个类和相应的表层次结构

选项2：使用类型属性创建单个购物车项目，该属性将标识属性的类型。在这种情况下，特定购物车项目的无关属性将为空

我知道这是一个非常基本的问题，但我想知道人们是如何遵循最佳实践的

---

提前感谢。

在我看来，当您的应用程序必须处理新事物供人们购买时，您似乎不想编写新代码。因此，当有新的物品要买时，一个新的类是一个糟糕的设计。

我会为此使用策略，例如：

public interface CartItem{
  String getName();

  BigDecimal getPrice();
}

仅在购物车中使用此界面。这样，如果您想要一个新的购物车项目，只要让它实现这个接口，它就会工作：）

---

通过使用界面，您仍然可以完全自由地设计实际购物车项目（可以是一个类，也可以是多个类）

这不是关于新项目，而是关于新项目类型。很明显，新的项目类型将具有新的功能。尽管如此，即使是一个小型零售运营商，其项目的拥有和更改的频率也比您想要编写新类的频率要高。是的，当然这是一种新的项目类型，但是如果您的需求包括让这些项目具有新的功能，那么这是一个很难编程的系统。在我决定必须这样做之前，我会评估一下可能会出现的新功能。我明白你的意思。所以我可以说，如果它有很多新功能，拥有新的类会很好吗？很难想象我会因为购物车中的商品的“附加功能”而创建一个新类。对购物者来说，这是他们决定购买的物品。它有定价、照片、说明、SKU编号、供应商、装运重量和时间、可用性等。这就是购物者在购物车中查看商品的方式。从毛衣到二手车，从坎特洛普到照相机，无论什么，变化都不大。许多刚接触OO编程的人太过努力地将他们的问题融入到他们可以使用继承的东西中；尽量不要这样做。避免这种代码是一个好主意，但在任何规模的软件系统中，决定类设计都不是一个好办法。从系统的基本需求开始，考虑它将拥有的对象类型。考虑系统中哪些内容可能经常更改，以及如何最大限度地减少由于您可以猜测的需求将更改而导致的代码更改。创建类来建模这些需求和更改。然后考虑基本的编码部分；如果您发现需要像您提到的那样有问题的编码实践，那么请重新考虑设计。