如果我想编写一个名为Mug的类，那么有一个类型为IContent的成员（它是一个接口）来描述一个马克杯的内容是否正确？
答案 0 :(得分：1)
如果宇宙是一个巨大的杯子怎么办？如果足够大，一个杯子可能包含任何东西。因此，在我看来，无论你的世界能够容纳你的杯子，都应该能够坚持下去。它可能包含很多东西。
对于宇宙本身而言，“马克杯”这个词毫无意义。这只是一堆问题，在某些时间范围内，人们会用特定的形状与自己保持接近。然而，对于我们的人体模型，杯子是一个离散的物体。它具有形状，大小，颜色和功能。然而，它的内容并不是概念杯的一部分。一个装有马克杯的杯子不是一个超级杯子也不是一个带水的马克杯。
由于内容是一组事物，无论是离散的还是连续的，甚至是两者，很明显内容和内容的概念是两个不同的概念。当我们将水视为杯子的内容时，我们简单地混淆了我们的想法。当我们扔掉水时，杯子的内容是否会消失？当我们喝咖啡时，它会再次出现吗？
马克杯是一个离散的物体。它有明显的界限。连续体，如液体或原料，不会。我们称所有形状和大小的水为水，而一个杯子在它开始变得像杯子一样起作用时就不再是粗陶器。我们通常对液体的形状和大小不感兴趣，但我们确实想知道我们的杯子是多么饱满。一个是另一个的功能。当以离散对象的形式描述时，内容具有不同的含义，然后当根据连续体描述时。一个是根据一组事物来描述的，而另一个是根据一定数量的东西来描述的。两者都涉及完全不同的数学集。为了使事情更复杂，内容也可以是两者。
因此可以对不同类型的内容进行建模。然后，那些不同类型的内容可以应用于不同类型的容器。玻璃杯和杯子的内容类型可以类似，而过滤器和杯子的内容类型可以不同。如果他们不这样做，那么您可能希望将容器类型建模为不同。如何建模取决于您可能想要回答的问题。过滤器可以容纳什么？或者在水离开过滤器之前需要多长时间？
从以上如下：
内容概念和容器概念有很强的关系，但有合理的理由将它们建模为两个不同的概念。
内容和内容也是不同的概念。
根据您的用例内容，因此可能是值得建模的概念。
但有一点需要注意的是，我们通常不会考虑具有内容的容器。我们只是想到有内容的容器。我认为IContent接口作为Mug的成员存在可能是合理的原因，但是以这种方式将此成员公开给Mug的用户不遵循最不惊讶的原则。你使用的和你暴露的东西不一定相同。 Java的HashMap类使用Entry类来存储键和值，但您可能永远不必直接使用此Entry类。
最后，什么正确完全取决于您的需求。保持简单，但不是太简单。
答案 1 :(得分：1)
当然这是正确的。这完全取决于你的造型......对我来说，它似乎是正常的选择。描述内容的不同类必须实现IContent接口，每个人都会很高兴......