Articles on Design patterns
Last updated: 2022/03/10
Top deep-dives on Design patterns
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.
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 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.
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.
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 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.
Andy Chu explores how the narrow waist concept aims to reduce interoperability issues (using the internet as an example), and elaborates on why it should be applied to the shell and distributed systems.
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.
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.
Vitalik Buterin discusses the differences in encapsulated and systemic complexity using cryptography functions as an example.
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.