Blog # 4 Design Patterns (Accidental and Intentional)

During my career as a software engineer, design patterns were heavily used by some clients, and were not used at all by others. I was exposed to them early on by a developer at UNISYS while developing a Windows based control system for NTSB. At that time, there were class library extensions in the marketplace which were commonly used to enhance UI and database access development. We had the opportunity to code our own classes using their framework, as week as modify their code. In order to use their code in a proper way, you had to really understand it, which involved studying the extended class library code and documentation. While doing so, I became familiar with 4 design patterns they had heavily used. These were Singleton, Observer, Iterator and Builder patterns

My architecture class has shown me 3 new patterns I am very impress with. The memento, strategy, and the facade pattern. The class focused on the strategy pattern primarily, with some concentration on the Singleton. Memento and Façade patterns.

I will focus on the benefits of the strategy pattern for this blog entry because I found it to be eye opening. It is very powerful and useful, yet I hadn’t known of it specifically prior to the class. It turns out I had used this pattern many times without knowing it.

Many project I have worked on had objected oriented class libraries, where a solid grasp of OOP programming skills were necessary in the mid-to late 90’s and early aughts. Interface based technology grew into the class libraries and class library extensions, where interfaces became a really useful tool. There were times I coded directly from an interface (when trying to implement a specific API, or to a specification requiring a specific interface), and other time would purely use the Object hierarchy. There were times I had probably used the strategy pattern BY ACCIDENT! By knowingly combining interfaces and OOP with the use of the strategy pattern, a much better design can be constructed where you get the best use of both technologies.

I find the best way to concisely describe the power of this pattern is to quote from the “Better Programming” website [1]

Advantages of the Strategy pattern

1. It’s easy to switch between different algorithms (strategies) in run-time because you are using polymorphism in the interfaces.

2. Clean code results, because you avoid using conditional-infested code (not complex)

3. More clean code, because you separate the concerns into classes (a class to each strategy).

I wish I had had a clearer understanding of this pattern years ago. The example in the Homework using Duck classes was particularly easy to follow, and really showed the symbiosis of interface oriented and object-oriented methodologies in clear way, stressing the benefits of coding to separation of concerns in a well-structured project.

Design Patterns are broken up into Creational, Structural and Behavioral classifications as a way to direct the designer to the appropriate top-level category.