The ideas of “is a” and “has a” are often discussed as part of object-oriented design. These concepts may seem simple and obvious. However, they can often be confused, and complex systems can blur the lines between them. We start a multi-part episode going over these concepts focused on how “is a” relationships work.
Is A and Has A Defined
These concepts boil down to simple grammar. For two objects, A and B, here are the options.
A is a B if A has all of the traits of B. For example, a poodle is a dog because a poodle has the traits we equate to a dog. A dog is not a poodle, as some dogs have traits that are not shared with a poodle.
A has a B when the entirety of B exists within A. A dog has a tail. The tail does not exist on its own away from the dog. More simply, a car has a color. In these relationships, multiple things can have the B part of the relationship.
One Way Relationships
For our purposes, these are one-way relationships. When A is a B, B is not an A. Likewise, when A has a B, B does not have an A. The color does not have a car; the tail does not have a dog. These definitions can seem to break when we replace names with instances. A father can have a son, and a son can have a father, but that is not a definition of contained properties. This example would be a relationship or pointers and not attributes that are contained. You have a height no matter what. You may not have a father if he passes away or something like that. As you can see already, grammar can confuse the situation, so we will continue to dig into these concepts and applying them.
