The Open-Closed Principle perfectly explains the replicator from Star Trek
Imagine Picard walking up to a replicator and ordering his favourite drink, as he always does:
"Tea. Earl Grey. Hot."
It materialises and our captain can get on with his continuing mission to explore strange new worlds.
But now, consider an alternate timeline, where replicators kinda suck. Imagine I was using the replicator, and said "Computer. Latte." but the replicator had no idea what I was talking about.
I'm not too sure that's a timeline I want to happen.
Bad replicator system design
The replicator's recipes are hard-coded and there's no way to teach it anything new.
The only option is to get La Forge to rip out the replicator system (which is currently working) and modify it to include our latte recipe.
In case you missed this episode, here's how it goes:
Earl Grey stops working.
Our captain only gets hot milk, with no glass.
The milk short-circuits the replicator system.
The system failure cascades to the holodeck and causes the safety protocols to go offline.
Obviously, this is not a real scenario. La Forge would never make such a mistake. But it does demonstrate a classic consequence when a system wasn't designed considering the Open-Closed Principle.
Only part of the replicator needed changed, but La Forge had to cut through everything that was working to reach it.
Changing a working system to add a new feature always carries risk. And since these systems were coupled in unexpected ways, we've now put members of the crew in danger.
But what other choice did we have?
I can't boldly go anywhere without my morning coffee.
Good replicator system design
Thankfully, that isn't our timeline.
The replicator may not know my favourite drink, but it doesn't need to. Because, in our timeline, the replicator was built to accept new recipes.
A replicator system that is open for extension means I can add a new recipe.
A replicator system that is closed for modification means I don't have to alter the guts of the machine to do it.
The replicator system itself stays shut. Earl Grey still works, the holodeck safety protocols are not at risk, and we can extend its programming to brew a latte.
What open and closed actually mean
Closed for modification doesn't mean nobody ever opens the replicator. You'll find La Forge down a Jefferies tube with a panel off something every single week, and that's fine. But wanting a latte isn't a reason to do it.
Open for extension means the system is designed to accept new behaviour. Recipes are added in such a way that a replicator never knows what a latte is.
It works because of the contract in the middle. The replicator will simply make anything that fits.
In your codebase that contract is the interface, and the recipe is whatever implements it. A class, a strategy, a handler, a plugin.
Nothing's closed against everything, though. Ask for something the replicator wasn't designed to produce and you'll be sending La Forge down another Jefferies tube.
So, just remember: adding a latte shouldn't require opening the replicator.
This is a metaphor I'm developing for an upcoming video on the Open-Closed Principle.
If you like patterns and principles explained using metaphors and analogies, you might enjoy my videos:
