Archive (p. 1)
In 2016, Cal Newport introduced a new term into the business lexicon: deep work. It’s an idea that has since taken hold of disaffected knowledge workers everywhere, due in no small part to the promise that they could finally start doing what they were hired to do--create value. More importantly, intertwined with this promise is something more nebulous--something fragile and fleeting. Dare we call it self-actualization?
Much has been made of the question about what it is to be an informed citizen. We’re instructed to “read widely,” “engage in debate”, “seek out new viewpoints,” etc. The message is clear: the more information you consume, the better informed you will be. On its face, this is reasonable and well-intentioned advice. The problem is that it’s also completely wrong.
In the modern sense, we think of a meme as a funny photo, or catchphrase, or joke that comes into our lives for a fleeting moment, typically via the Internet, and then goes on its merry way. But there is something arguably more sinister to the process. To us, the exchange of a meme is a bit of levity, but to the meme, the exchange is a question of survival. To propagate, to live, the meme must spread.
In object-oriented design, one of the principle aims is to produce code that is flexible, maintainable, and reusable. One of the ways to do this is to use abstractions in your code rather than concretions. The more your objects know about how one another are implemented, the more dependencies there are in your system. As the number of dependencies grows, the potential for cascading breakage grows as well. But what happens when you have a system that requires certain objects to come from the same family?
In some situations, it may be preferable not to mutate a given object. Or more likely, you won’t even have the option of mutating an object because it may come from a codebase over which you have no control (such as an external library). Such cases are relatively common; however, it’s still possible to enhance an immutable object’s behavior. One effective means to do so is with the decorator pattern.
One of the benefits of object-oriented design is the ability for objects to share some behaviors while simultaneously differing in others. Typically, this is achieved through inheritance--when many subclasses inherit properties from a parent class but can optionally override certain behaviors as needed. This is a very useful and common design pattern; however, there are situations when polymorphism through inheritance is inappropriate.
In part 4 of the SOLID series, we continue the discussion of decoupling and how to avoid so-called 'interface pollution', wherein classes are unnecessarily forced to implement behaviors that they don’t need. It is here that our next SOLID principle appears: the Interface Segregation Principle.
Archive (p. 1)