To non-developers, software development can seem impossibly complex and difficult. For a writer and designer like myself, reading through lines of code is like trying to read Latin.
But as I’ve learned more about the processes here at Red Cedar, I’ve discovered that many tricks of the trade translate back to common work processes in other industries. This is no more evident than in design patterns, which are reusable solutions to commonly occurring problems in software. Design patterns aren’t a specific third-party software tool, or even individual pieces of reusable code. They’re a way of organizing, architecting, and thinking about code at the highest level, using known methods in a specific way for a predetermined result. These patterns function as standards for building new software, and their names are metaphors that relate commonly known concepts to the pattern’s uses, such as the factory pattern, builder pattern, mapper pattern, and decorator pattern.
The factory pattern is one of the most popular in software development. At was designed by the “Gang of Four”: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, the group that authored Design Patterns: Elements of Reusable Object-Oriented Software. The factory pattern will “define an interface for creating an object, but let subclasses decide which class to instantiate,” the book states. “The Factory method lets a class defer instantiation it uses to subclasses.”
That explanation is likely confusing for non-developers, but what it actually means is quite simple. The factory pattern makes it easier to create new things by having the methods to build them pre-built with the tools used to create them.
For example, a factory used to make cars isn’t recreated each time a new type of vehicle is being built. Instead, the assembly line is already set. From there whatever machines or process(es) are required to build the cars is determined by the type of car itself. The factory knows what type of vehicle to make, but knows nothing about the engine, the color, the tires, and any other features. The vehicle itself knows and directs the machines to perform these actions as it goes through the assembly line. The only thing the factory actually has to do is determine what type of car to create.
Another common design pattern is the decorator pattern. It “allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class.”
If we’re working in the same factory, this pattern would allow a new command for a machine, such as “paint sedans blue,” to function without overriding or in any way influencing the same machine’s other existing functions, such as “paint pick-up trucks red.” The same machine can function for both purposes, without needing to be duplicated or re-set for each new vehicle along the line.
Our developers work with design patterns every day. MI School Data serves the same purpose it did at its first creation, but its function has updated and changed greatly over the years, as it must do to improve along with the growth of technology.
Design patterns aren’t perfect; they force a certain rigidity within language and functions of the software. However, at Red Cedar we’ve found that they decrease maintenance, facilitate comprehension, and speed up the development process. And those are outcomes that anyone can understand.