Oop 面向对象的食品配料类设计

我想向我的用户推荐菜谱，所以我从

JSON

源代码（包括它们的成分）获取菜谱

目前，可以通过三种方式提取配料：

3西红柿

（无特定装置）

125ml牛奶

（体积单位，公制或英制）

500g意大利面

（质量单位，公制或英制）

要求 我想使用DDD方法，所以是分层架构

我需要能够按原样显示成分，就像上面我的项目列表中建议的那样。用户可以选择公制或英制视图

3个西红柿

125ml牛奶

或

1/2杯牛奶

55克意大利面

或

2盎司意大利面

我的挑战 我不确定如何设计类以尊重封装并确保易于维护的设计

我的第一个想法是用

单位

类来表示单位，因此我的

成分

类将包含一个数量和一个单位。但在某些情况下，成分是无单位的。考虑到这一点，我的

InCreditPresenter

将如下所示：

public String present(Ingredient ingredient) {
    if ( ingredient.isUnitless() ) 
        return ingredient.getQuantity() + " " + ingredient.getName();
    else
        return ingredient.getUnit() + " " + ingredient.getName();
}

我不相信这种方法，因为我可以有许多不同类型的

单元

，因此我的

IngredientPresenter

将快速增长（并且违反）

然后，我想我可以选择多态性。虽然这似乎是一种很好的方法，但我不知道在我的接口中公开什么，因为我的实现将完全不同。我需要在实现中公开我的方法，这样就失去了多态性的所有好处。我的

InCreditPresenter

如下所示：

public String present(Ingredient ingredient) {
    if ( ingredient instanceof UnitlessIngredient ) {
        UnitlessIngredient actualIngredient = (UnitlessIngredient) ingredient;
        return actualIngredient.getQuantity() + " " + actualIngredient.getName();
    } else {
        WithUnitIngredient actualIngredient = (WithUnitIngredient) ingredient;
        return actualIngredient.getUnit() + " " + actualIngredient.getName();
    }
}

实际上，我认为我的问题是我不知道如何正确地表示单位，所以我正在寻求您的帮助

谢谢你抽出时间

编辑

---

我不仅会介绍我的配料。在我的领域层，我需要计算成分的营养成分。因此，根据其数量（或体积或质量），计算方式有所不同。一个简单地将营养成分乘以数量，而另一个必须按比例进行。这是多态性的完美例子。

肯定是多态性

通常的做法是，

present（）

不再是真空中的独立函数，而是成为

成分的一种方法

因此，您基本上调用
成分
，将其自身呈现为字符串。可能有一些参数指示公制与英制，成分可能有一些用途，如果没有单位，则可能忽略。简单、优雅、久经考验，效果很好。
这是个好主意，但它不允许我以不同的方式展示我的配料。假设我有一个简短的演示和一个全文演示。此外，我的
成分
类（在域层）知道它的表示（在更高的级别）。第一部分：完全没有问题：向
present（）
添加一个“缩写”标志，或者将其拆分为两个方法：
presentabreviated（）
和
presentFullText（）
。第二部分：（“此外，…”）我不理解。这样做，我们违反了，或者换句话说，我们需要添加方法来添加功能。我还有一个问题，我需要持久化我的成分，因此我将有一个方法将我的类转换为持久化的
DTO
。同样，我想更改我的持久性，这意味着我需要添加一个新方法：）。在DDD方法中，您的域层不应该知道（或意识到）其他层。哦，我明白您的意思。嗯，如果你真的想对设计原则如此挑剔，那么是的，这个答案是不合适的。另一方面，你可以选择放松的设计纯度，以利于生产力，换言之，认为这一方法是一种务实的妥协。（因此，打破开放/封闭原则，多态表示就能完成任务。）在更复杂的项目中，在更接近设计核心的课程中，我会努力追求纯净；但在您描述的场景中，这可能不值得。除非这是一项旨在找到如何以尽可能纯粹的方式完成任务的练习；在这种情况下，我们希望会有更多的答案。DDD体系结构不存在。你似乎在试图过度设计解决方案。保持简单，按图案看。对于你的无单位配料，只需使用一个单位的“块”。