Object Oriented (OO) Design is often misunderstood and generally misused, or at least, underused. With proper implementation of OO techniques, development can become smoother and more streamlined. Changes become easier to introduce and implement, and when using an agile development process, development becomes more agile.
Let’s look at the benefits of a few design patterns, especially focusing on the ones that help save time and money:
The Factory Pattern
Factories, Factory Methods and Abstract Factories are used to group together related objects and introduce a single point of entry to interact with them. For example, if an application needs to support multiple databases, the Factory pattern can be used to hide the database specific protocols to upper layers in the architecture and to determine which database configuration is currently being used. The beauty of this pattern is, if implemented correctly, additions to the factory (such as introducing a new database to support) do not require changes to the existing code, but only additions. This of course reduces testing complexity, hence saving time.
The Builder Pattern
The builder pattern assigns the building (construction) of complex objects (such as reports) to a Builder object. The cost benefit of this is that it allows for quick resolution of errors that may arise in handling these complex objects since there is a single construction point.
The Command Pattern
In this pattern, each “command” or request in an application is encapsulated in an object. This facilitates changing the request requirements, such as what information is submitted on a form, by changing only the single command object, without having a ripple effect on the rest of the application. Once again, testing complexity is reduced and time overhead is cut.
The Controller Pattern
There are several variants of the controller pattern, but the prominent one advocates using a single “controller” class for a distinct use case. The advantage here is ease of troubleshooting and a streamlined change process for requirement changes or updates.
The Mediator Pattern
A mediator defines how a set of complex objects works together. This is useful with complex business logic to make easy updates on change requests without having to redefine object relations throughout the application.
The Template Method Pattern
The template method pattern allows for a business process to be partially implemented, while delegating implementation-specific chunks to implementation objects. This facilitates the implementation of flexible requirements by allowing change and easy prototyping in cases where the product behavior is experimental or not completely specified or agreed upon.
The Adapter Pattern
The adapter pattern accommodates the creation of an adapter to emulate a similar process in another branch of the product. This obviously saves time, both during development and testing, for applications that have similar behaviors in multiple parts of the application (such as creating records in the database). It also makes the application more extensible to new features that continue the trend of the similar behaviors.
The Decorator Pattern
The decorator pattern allows the behavior of the application to change dynamically. If implemented correctly, it can change or add behaviors to the current application without modifying existing code. This naturally lends itself to flexible requirements, as well as reduces development time on upgrades.
Of course there are many more patterns that can improve the design of an application and make it easier to maintain, and a sturdier frame to work on. The overall objective of using such design patterns is to increase overall efficiency and sustain an agile development environment. This in turn helps to reduce both production and maintenance costs.
