Design Patterns

Really, I could have been discovering and documenting these for years had I known to look for them. Now that I have learned to think in this way I see them everywhere. A design pattern is a powerful concept that I've learned of all too late in life. The design pattern is a loose way to classify a general form of a solution to a general class of problem. A problem may have multiple good design patterns that can solve it (and perhaps even more less well-fitting design patterns that could less wisely be used). Using the language I now know, a big mistake I've made in the past was to view learning software as an attempt to find the ultimate design pattern; one single pattern so good that it solves all problems.

Reality is both more complex and less boring. Design patterns more resemble the tools in a machine shop. Cutting a board in half can be done on a milling machine, but it's far more appropriate to use a chop saw. Sometimes it's less obvious - a tablesaw and a bandsaw are both appropriate for long cuts down a board and the choice between the two is nuanced. Some tools are built for very specific purposes and see little use; others can be used to make almost anything.

With this page, I aim to catalog and document my exploration of design patterns - to build out my tooling collection, so to speak.

Catalog

For now, this is a long unordered list. Perhaps as the collection grows I'll discern more intelligent ways of organizing them.

The Singleton

A class which only ever has one instance.

Onion Architecture

Hexagonal architecture, clean architecture, et. al. This architectural method goes by many names and provides a way of organizing dependencies, backing services, and testing. The rules governing the design are simple and their adoption limits intractability. An excellent balance between modularity and integration can be achieved.

The Repository

Specifically an onion adapter. A special form of adapter when dealing with CRUD operations.