Patterns

Patterns are generally taught in isolation (separation of concerns), but application of patterns is often highly interconnected. Here I’ll show how my most used patterns come together as a design system.

I previously wrote on how static members on a struct work as a more extension-friendly enum. This pattern has gotten even better as of C# 9.

Understanding Clean Architecture has transformed my approach to architecture. Now I feel like my understanding has evolved one step further by understanding its parent pattern’s name, Ports and Adapters.

A general design for integrating notifications (email, text, push, etc) has long eluded me. However, a recent refactor using the concepts of Synthesizing Project Organization Methods has settled my search. Here I’ll explore my refactoring experience and why the conceptual shift is generically more stable.

C# (and Java) offer a type call enum (aka enumeration). It represents a fixed list of possible values and is a powerful tool for communicating intentions through the type system. However, a recent legacy project forced me to face the shortcomings of enums and realize an even more powerful pattern, struct named constants.

I got to thinking about the Rediscovering Options post. The volatility analysis portion is an important artifact of my design process. The current version requires reading the whole list to comprehend the results. How could I make it better?

Configuration is a powerful tool and a dangerous temptation. My goal in this post is to walk through the ways I mishandled configuration, ended up rediscovering the Options configuration pattern, and finally dive into specific design scenarios to show why Options is the most stable solution.

“.. the high-level language embodies the constructs wanted in the abstract program and avoids all the lower ones, it eliminates a whole level of complexity that was never inherent in the program at all” – Fred Brooks, No Silver Bullet