Articles on Design patterns

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'.

A gentle introduction to Domain Driven Design

The Lone Architect discusses the different steps that can be taken to move from a simple transaction script to a more complex domain-model code. The author starts with Active Records, which abstract away the database implementation details, and then moves to a service that encapsulates domain logic. This results in less duplication and more readability.
Some highlights:

• Domain driven design (DDD), roughly speaking, is splitting up code based on what category of business function it falls under
• It's not a fix all methodology; don't over complicate solutions to simple problems
• There are different degrees at which DDD can be applied

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.

Organizing Code by Feature using Verticle Slices

I hated working with Angular (web dev framework), because it split up all of the code relevant to a page or component into 4 different files. The mental fatigue from switching between files and keeping track of everything just to switch one thing was too much for me. Unsurprisingly, there are people who agree, and in this article, Derek Comartin shows with an ASP .NET example the advantages of using the titular approach.