Articles on Design patterns

Last updated: 2022/03/01

Top deep-dives on Design patterns

Climbing Mount Effect

Let's just get this out of the way from the start; the header on this site is insanely cool. With that done, in this article Steven Wittens discusses the advantages of using a declarative style of programming. Steven highlights the quickly growing complexity of an imperative system using a typical website example and how repetitive, but simple design for handling effects can be more advantageous than a more common approach using unique steps.

How humans write programs

I think one of the key characteristics of being a good programmer is creativity. Why? Because when it comes to implementation, I rarely find that my first idea is the one I end up sticking with. Being able to come up with a lot of different ideas, filter out the really poo-poo ones, then polish the rough ones into sparkling gems is a universal process for creating great things. In this first article, Ted Kaminski discusses exactly this process, and plants the idea of how it could be improved or fast-tracked.

Component-Oriented Programming

Component based software engineering has been around since at least 1968, and has been popularized even more in the past decade thanks to web frameworks like React. It's still really applicable to all areas of programming. Brian Picciano's article defines what a component is, provides an example, illuminates the benefits, and addresses some of the glaring criticisms.

Geometric effects of certain system design choices

Following along in the design pattern trend, this article by Rachel is written in a more casual manner, but still focuses on highlighting seemingly harmless design choices that can turn into major issues down the line. Rachel explores the different bad design choices made for a service, and concludes with better alternatives you shoudda picked.

Preemptive Pluralization is (Probably) Not Evil

For those of you who've been here a while, you know I'm a stickler for some good ol' code philosophizing. Mostly because everyone can work hard, but it takes some patience to learn to work smart. And philosophizing can help! Shawn Wang proposes that pluralizing prematurely (sounds dirty?) might not be the worst idea, because 'the nonlinearity in how expensive it is to make a change comes from the "emergent sclerosis" of code'.

Command Line Interface Guidelines

Command line interfaces are probably among the oldest pieces of software that have been available for users on computers. After taking the plunge and switching to Arch as my first Linux distro, I've come to prefer the command line to GUI for most tasks, and CLI programs have a special place in my heart now. In this design document, Aanand Prasad, Ben Firshman, Carl Tashian, and Eva Parish layout a number of design principles and examples to follow when it comes to designing programs that require user interaction in the CLI.

CUPID—for joyful coding

Daniel Terhorst-North iterates on the SOLID design principles and comes up with his own acronym CUPID, which stands for Composable, Unix philosophy, Predictable, Idiomatic, and Domain-based.

Patterns of Distributed Systems

Distributed systems can be a pain to work with because you have to account for a lot of issues that don't normally arise when working with one system; keeping the systems synced, handling a single system failure, caching, and race conditions. Good design is necessary to have a succesful system. In this extensive series of articles, Unmesh Joshi outlines the problems faced in distributed designs and a number of patterns aimed at solving them.

Encapsulated vs systemic complexity in protocol design

Vitalik Buterin discusses the differences in encapsulated and systemic complexity using cryptography functions as an example.


Want to see more in-depth content?

subscribe to my newsletter!

Other Articles