Creational Patterns, inheritance, and Object Composition for Web Developers
The conceptual fundamentals of object instantiation patterns
This article is the first in a series intended to explore creational patterns, one of three design categories presented by the Gang of Four (GoF) in Design Patterns. I’ll be delving into several specific patterns by introducing their benefits and detriments, use cases, and best practices. This post specifically goes over two lower-level patterns, inheritance and object composition, which are helpful for understanding why the various creational patterns are uniquely beneficial and disadvantageous.
Creational patterns are those concerned with the creation and organizing of objects in useful ways. That is, creational patterns define and abstract the instantiation process.
The five creational patterns I’ll be exploring in this series are Singleton, Factory Method, Abstract Factory, Prototype, and Builder. Factory Method can be better understood as an inheritance pattern implementation, whereas Abstract Factory, Prototype, and Builder are more reliant on an object compositional model.
Without having experience in managing larger codebases, it may be difficult to grasp the significance of these patterns. Generally, as systems evolve over time, the larger and more complex they become. This results in the need for objects to reflect a more specific and well-defined set of user stories, which is more conducive to object composition. According to GoF:
“Object composition lets you change the behavior being composed at run-time, but it also requires indirection and can be less efficient. Inheritance lets you provide default implementations for operations and lets subclasses override them…[but] can [not] change at run-time” (GoF, 33).
Inheritance is useful for creating groupings of object families based on what they are, organized in a hierarchical taxonomic structure, whereas object composition is concerned with what the objects instantiated are meant to do; their intended functionality.
The problem with inheritance becomes clear when we try to create an object that has features from multiple classes, at which point the developer is forced to painfully reorganize their hierarchy and all of its instantiations. This anti-pattern is solved by the utilization of object composition, which allows for flexible object creation independent from how they are related to other instantiations.
To make this clear, consider the following example of a system that allows for the creation of specialized kinds of animals and robot objects:
Great! Now that we’ve been asked to create a cleaning robot monkey for our program, the systems outlined above would back us into a corner. If you must maintain the inheritance structure, one solution would be to add a monkey subclass to the cleaning class, or the structure could be reorganized to accommodate for a wider range of object categories.
In this oversimplified example, it may not seem that significant to have to reorganize. However, once working in a larger application that makes use of inheritance, alterations would more than likely create bugs throughout the system, exacerbating the issues of redundancy and debugging while maintaining functionality.
The more persistent problem is one of code duplication, another possible source of programming debt. In relation to the example, monkey-robots would have all the same monkey functionality as plain old animal monkeys, but they are in mutually exclusive branches in a tree of classes. Let us look at how this could be better solved using a model designed around object composition:
As can be seen, this pattern is much more flexible than the previous and allows for creating objects with the properties of reusable prototype-like objects. The request of our project manager to create a cleaning robot monkey can be easily fulfilled without the struggle of reorganizing the creation system. Any combination of the reusable objects can be composed to create instances which had not previously been considered.
Think of the reusable objects as sets of ingredients; now when your project manager asks you to make a guard dog, cooking up the product is as simple as declaring the recipe of that product’s intended functionality. In this case:
let GuardDog = Animal + Dog + Fighting;
Easy as pie!
The greater degree of flexibility offered by object compositional models keeps us, as developers, from getting ourselves stuck up a creek with a broken paddle. In stark contrast, “Inheritance encourages you to build this taxonomy of objects very early on in your project, and you are most likely going to make design mistakes doing that, because humans cannot predict the future (even though it feels like we can), and once you’ve build yourself into that inheritance taxonomy, it’s really hard to get out of it” (M. Johansson).
To sum up: inheritance creates a systems of class hierarchy which may be initially intuitive but can present problems in the task of system scaling, where object composition may be more complicated and computationally intensive, but allows for products in the program to be flexibly built and adapted with the changing requirements of the system.
Next in the series, I’ll be going into the most simple of the creational patterns, Singleton, which is not directly related to the two patterns discussed above. From there, I’ll dive into the other four which may be categorized as more so inline with an inheritance or object compositional model.
Leave any questions or comments below! All feedback is appreciated.
Jacob
Design Patterns for Web Developers series:
