Our language can blur the distinctions of class relationships in designing our solution. The “has-a” determination is often confused by how the English language can translate those words. We also have to keep a context for assigning a class. Likewise, reality allows for data to be multiple classes in some cases, so we need to examine how those might be a hierarchy of some sort.
Class Relationships – “Have” As A Pointer
The confusing aspect of the English language is that we can “have” a relationship and a property. For example, you have an age, and you have a parent. The age is a property of being you while the parent is a relationship. This language blurring of properties can be confusing to those new to the idea of object-oriented design.
Does It Stand On Its Own?
The way to look at these different aspects with the same name is whether the target is itself an object. That is, can it stand on its own apart from the “owning” class. In our prior example, your age has no meaning apart from you. That age is not something you can give to someone else. Others have the same value for their age, but it is not the same age we are referring to. Your parent exists outside of you, and others can have that same parent.
The Impact Of Change
In the software world, it may help to look at what happens when the target property changes. Does it impact any other objects? If I change your name (a property you have), that only impacts you. It does not change anyone else’s name. If your car changes, that impacts you and anyone else that links to that car. This is one of those data facets we see all the time. Do we copy a value, or can we have multiple pointers to it?
