Even if classic design patterns fall out of favor, they at least can teach us the importance of a shared idiom. This benefits all areas of coding.
Join the DZone community and get the full member experience. There’s not much buzz about design patterns these days. They appear to have joined the hall of fame of accepted wisdom, alongside the Silver Bullet, SOLID and DRY. Lately, I had the opportunity to share some thoughts on the importance of good old design patterns with Koen Aerts, CTO of Team Rockstars IT. Here’s the gist of that talk in a more digestible format. Before I start, let me set some boundaries, as people can get doctrinaire about definitions. I refer to the good old bridge, builder, decorator, and factory patterns. Architectural patterns like MVC do not fall into the same category, much fewer paradigms like serverless and microservices (aka SOA the next generation). Then again, the latter do constitute a legitimate grey area. They’re clearly about design, patterns, and best practices as well. They offer standard solutions to common challenges. But what makes them different is the scale at which they operate. Classic design patterns are recipes for manageable bits of code, solutions that often fit in a single screen. They explain how to stack the bricks for your new house, whereas microservices show you how to lay out the entire neighborhood. Design Patterns: Elements of Reusable Object-Oriented Software, aka The Gang of Four book narrowly preceded Java’s quest for world domination. It’s quite a feat for a programming book written in 1994 to be still in print, but it has not weathered the test of time equally well as other classics like The Mythical Man Month, published nineteen years earlier. It makes sense. Brooks talked about the human condition without a single line of code. The GoF offered hands-on coding advice using contemporary languages, which necessarily dates it. The scenarios themselves have not aged, but the solutions have. Although these design patterns are in principle language agnostic, many are unique to the challenges of OO: creating objects (builder/decorator), using hierarchies (bridge), dealing with polymorphism (abstract factory) and isolation (adapter). Old school Object Orientation of the imperative and stateful flavor is falling out of favor.
