flippant remarks about my use of design patterns
Seasoned YouTuber Derek Banas has a design patterns series that I think I should watch at least once a year to stay in shape. This exercise should inspire me to answer these very healthy questions:
- What design patterns am I using regularly?
- What design patterns am I not using regularly?
The last question is harder than the first question, making this professional introspection quite difficult. All of this babble, by the way, can be blamed on Eric, Richard, Ralph and John—the Gang of Four.
What design patterns am I using regularly?
- Singleton Pattern
- Template Method Pattern
- Strategy Pattern (with the Command Pattern)
- Façade Pattern
It feels like the number-one design pattern that I know I am using regularly is the Singleton Pattern. My TraceSources class in SonghayCore is a singleton.
The number-one design pattern that I continually do not know that I am using regularly is the Template Method Pattern as this pattern comes closest to my frequent use of extension methods. My SonghayCore repo has over 60 class definitions devoted to extension methods.
The the number-two design pattern that I know I am using regularly is the Strategy Pattern. My dictionary of Lazy<IActivity> field in my ActivitiesGetter can hold several different strategies for what happens when IActivity.Start() is called. (And I argue that the Command Pattern is used via ProgramArgs to select these strategies). What is definitely controversial (because OOP is not in use) features my use of Action<T> or Func<T> in some of my SonghayCore utility methods (like Action<string> fileAction in the FrameworkFileUtility.ReadZipArchiveEntries() method). I assert today that any use of Action<T> or Func<T> is ‘a kind’ of Strategy Pattern.
The the number-three design pattern that I know I am using regularly is the Façade Pattern. This pattern is synonymous with the acronym API and, in my world, largely in use in my ASP.NET Core projects.
What design patterns am I not using regularly?
- Decorator Pattern
- Visitor Pattern
- Flyweight Pattern
The number one design pattern I am not using is the Decorator Pattern. This is important because have been one of those people that have confused the use of extension methods as ‘a kind’ of decorator pattern. There is a StackOverflow question posed almost a decaded ago around making this mistake.
The number two design pattern I am not using is the Visitor Pattern because this pattern has also been confused (by me) with the use of extension methods.
My limited research suggests that Decorator Pattern and the Visitor Pattern came from needs around trees of objects. This flippantly makes me associate these two patterns with the pattern related to addressing large numbers of objects, the Flyweight Pattern.
The following table summarizes my ignorance of the remaining patterns covered by Derek Banas:
| pattern | flippant remarks |
|---|---|
| Adapter Pattern | To date, after almost two decades, I have failed to see an “incompatible interface” problem. It is just possible that I am not aware that I was using something like this when strangling legacy WPF code into Prism services. |
| Bridge Pattern | Today, this sentence is beyond my comprehension: “The class itself can be thought of as the abstraction and what the class can do as the implementation.” |
| Builder Pattern | I assume that my use of StringBuilder and any other .NET Standard class with the suffix *Builder has been at my disposal for years. |
| Chain of Responsibility Pattern | Today, my ignorance suggests that this pattern is associated with the need to avoid using if structures in the design of a ‘rules engine.’ Alternatively, I may find that this pattern is used for ASP.NET Core middleware. |
| Composite Pattern | This sentence, sadly, has no meaning for me at this time: “When dealing with Tree-structured data, programmers often have to discriminate between a leaf-node and a branch.” |
| Factory Pattern and Abstract Factory Pattern | I have spent most of my Microsoft-biased career as a consumer of factories (e.g. DbProviderFactory). A Factory is intended to centralize the instantiation of objects via method returning an interface or abstract class. An abstract factory uses the same method to return objects that can instantiate other objects. |
| Interpreter Pattern | This pattern relates to Domain Specific Languages and feels like it leads into the linguistics of artificial intelligence. |
| Iterator Pattern | This sentence is telling me that .NET data structures have been quite sufficient: “The elements of an aggregate object should be accessed and traversed without exposing its representation (data structures).” |
| Mediator Pattern | Traditional approaches to WPF event aggregation introduced this pattern to me. |
| Memento Pattern | My ignorance of this pattern betrays the fact that I have never built a professional “undo” feature in my career so far. |
| Prototype Pattern | Wow, this sentence shows that I am nowhere near a Java architect: “Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward abstract factory, prototype, or builder (more flexible, more complex) as the designer discovers where more flexibility is needed.” |
| Proxy Pattern | The need to use a smaller, more obscure object in place of the real one has definitely been in my life. The Azure Storage Blobs client library has loads of proxy patterns. |
| State Pattern | “This pattern is close to the concept of finite-state machines.” [wikipedia] And feels related to the Chain of Responsibility Pattern as both patterns should reduce or eliminate the use of if. |
outside of the Gang of Four: the producer-consumer problem
The producer-consumer problem is not a pattern. It’s a problem. I list this here with a bunch of design patterns because, once a pattern like the Mediator is implemented asynchronously, this problem needs to be known.
Decoupling asynchronously in my life implies that I am building for the cloud. And, sadly, there is a whole new bag of cloud design patterns.