OOD - The content of a mug is a property of Mug class? [closed]

Question

If I want to write a class named Mug is it correct to have a member of type IContent (it is an interface) which will describe the content of a mug?

Answer 1

Of course it would be correct. It totally depends on your modelling... To me it seems to be the normal choice. The different classes describing contents, would have to implement the IContent interface and everybody would be happy...

Answer 2

Meta-mug-physics

What if the universe is one giant mug? If big enough, a mug may contain anything. It seems to me therefore that whatever your world is able to hold your mug should be able to hold. It may contain a great deal of things.

To the universe itself the word mug has no meaning. It's just a bunch of matter that for some time range stays in proximity with itself in a particular shape humans would describe a mug. To our human model however a mug is a discrete object. It has a shape, size, color and a function. It's contents, however, are not part of that conceptual mug. A mug containing a mug is not a super mug nor is a mug with water a water mug.

Content and contents

Since content is a set of things, either discrete or continuous or even both, it is plain to see that the concept of content and contents are two different concepts all together. We simply muddle our thinking when we think of water as the content of a mug. Does the content of the mug disappear when we throw out the water? Does it reappear later when we poor in coffee?

Type of content

A mug is a discrete object. It has distinct boundaries. A continuum, like a liquid or raw material, does not. We call water of all shapes and sizes water, while a mug stops being stoneware the moment it starts to become functional as a mug. We usually aren't that interested in the shape and size of a liquid, but we do want to know how full our mug is. The one is a function of the other. Content has a different meaning when described in terms of a discrete objects then when described in terms of a continuum. One is described in terms of a set of things, while the other is described in terms of a volume of stuff. Both involve an entirely different set of mathematics. To further complicate things, the content can also be both.

One could therefore model different types of content. Those different types of content may then apply to different types of containers. The content type of a glass and a mug may be similar, while those of a strainer and a mug may differ. If they don't then you might want to model the type of container to differ. How you model it depends on what questions you might want to answer. What can a strainer hold? Or how much time will pass before the water has left the strainer?

Concluding

From the above follows:

1. that the content concept and the container concept have a strong relationship, but that there are legitimate reasons to model them as two different concepts.

2. that content and contents are also different concepts.

3. that depending on your use-cases content may thus be a concept worth modeling.

POLA and KISS

One thing that should be noted though is that we usually don't think about containers having content having contents. We simply think of containers having contents. I've argued that there may be legitimate reasons for the existence of an IContent interface as a member of a Mug, but exposing this member in this way to the users of your Mug does not follow the principle of least astonishment. What you use and what you expose do not have to be same though. Java's HashMap class uses an Entry class to store keys and values, but you might never have to use this Entry class directly.

Lastly, what is correct is totally up to what your needs are. Keep it simple, yet not too simple.