Atomic Inheritance

Rather than try to define mega do everything in the world super classes, why not use inheritance to your advantage by defining fine-grained hierarchies?

For example, consider the following class diagram.



Here, we have three classes; Content, User, and HTML. The Content class defines most of the functionality used in this partial design of a CMS. It is a very basic class that defines features common to the content abstraction. The User class is also missing basic features but this is for simplicity. The association relationship between the User class and the Content class is indicative that there is a User instance associated with each Content instance. Finally, the HTML class extends the Content class; HTML is a content type.

Atomic inheritance means that every class in the class hierarchy should be atomic. In this context, atomic is really only a guideline instead of a rigorous design requirement. Traditionally, in object-oriented inheritance, atomic refers to a leaf class. A leaf class is a class which has no children, a class with no further specializations. How then, do we build inheritance hierarchies using only atomic classes.

Again, assuming that the term atomic is only referring to a logical design requirement, it isn't too difficult. Lets take another look at our CMS example. The first change to note here is that both the Content and User classes define a name attribute and name behaviour. A logical atomic class here would be Name. The same example can be seen with the created attribute. Here we could create a new atomic class called Date.

You can hopefully see where I'm going with this. Typically, there is a decent mapping from attributes to atomic classes. Here is the new class diagram after refactoring.



As you can see, in this example of atomic inheritance, we have completely eliminated all attributes and operations from the User class. The class simply ties together two other atomic classes while at the same time reducing the size of the Content class.