Simple Design, Dependency Inversion Principle (DIP) Comments
We have standard workflows in our systems that programmers copy and paste from module to module in order to achieve some kind of standard behavior. Programmers call this boilerplate. If they extract the standard workflow from the boilerplate, then the copy/paste risk goes away, it becomes easier to gain confidence in the code, and everyone wins.

Read on →

Read on →

Comments

I recently encountered a code base in which someone had applied the Golden Master technique, but done so in a way I find risky, so I wanted to warn you against letting this happen in your code. This code exhibits a bad idea that probably started out as a good idea or seemed like a good idea at the time. This makes it plausible-but-risky, and this is where a lot of legacy code comes from.

Read on →

Comments

Today I’d like to share an example of a tiny cohesion risk. I leave it to you to evaluate the severity of the risk and the appropriateness of the refactoring. I like to deal with risks when they are small enough that their impact, while painful, probably won’t kill.

Read on →

Dependency Inversion Principle (DIP) Comments

If you want reuse, you have to make it happen. Fortunately, you don’t need to be psychic; it’s enough to start by removing duplication, which makes opportunities for reuse easier to spot. Let me show you an example from code I’m working on to generate Nginx server block configurations I need to support some pretty URLs.

Read on →

Read on →

Surviving Legacy Code, Dependency Inversion Principle (DIP) Comments

When you use relative include paths in your code, you bind each source code file to its current location in the project’s file layout. You relegate yourself to having to run it from a very specific location on the file system. You generally make it unnecessarily difficult to automate running your application (or its tests) outside your development environment, such as in platform-as-a-service environments. You make things like Docker not just helpful, but necessary.

Read on →

Read on →

Dependency Inversion Principle (DIP) Comments

The entry point. Sometimes it’s main(). Sometimes it’s an extension point in some complicated framework. Most importantly, it is the border where Their Stuff runs Your Stuff. When I see entry points in other applications, I don’t see a lot of evidence of having thought about the design much. It becomes a kind of junk drawer for code. This happens especially when programmers are working in environments they don’t feel particularly comfortable in. (I don’t know where to put things, so I’ll put them here, since that seems to work.)

Read on →

Dependency Inversion Principle (DIP) Comments

You might have noticed dependency injection gaining popularity in recent years. You might also have noticed some notable figures (I’m thinking of Kevlin Henney) who appear to be bad-mouthing dependency injection, when really they are simply taking away what they feel is a veneer of mystery from the term.1 I must say that I appreciate their doing so without pretentious use of the annoying word “demystifying”. (Simply ignore my own “demystifying” article by most certainly not clicking here). While on a three-hour-long car trip it occurred to me—some would say much too late—that injecting dependencies, particularly through the constructor, acts precisely like partially applying functions. This leads to a couple of potentially useful conclusions:


  1. I consider it categorically unfair to interpret what Kevlin writes or Chris Oldwood writes as “bad-mouthing” the concept of dependency injection, but unfortunately, a careless reading of their work might suggest that in the mind of the careless reader. They mostly object to coining a new term for an old idea, with which I agree. Even so, dependency injection remains known as a term of art, so I just want to roll with it.

Read on →

Design credit: Shashank Mehta