Understanding design patterns in programming gives us tools that work in many different contexts to improve the overall quality of our code.

We think the explanations you find online are far too complicated, so we've made it our (side) mission to simplify these so they're accessible to everyone. Let's look at 5 today:

YAGNI (You aren't gonna need it)

Real World Example
Imagine a couple - Jack and Jill.

Jack is living in constant fear of the apocalypse, and the resurgence of the black plague.

He's built a Doomsday shelter and he wears a biohazard suit everywhere he goes. He has a "you can never be too safe" type of attitude.

Jill feels frustrated for Jack and his over-compensation for things that are probably never going to happen. Jill understands the need to prepare for the future, but not to the point where you're investing a lot of energy for something which is highly unlikely to provide any valuable return.

In Programming Terms
Ok, that WAS an extreme example. In the business and personal project world, it's a little more subtle, so you need to think of YAGNI in the context of the business or project you're working within.

I.e, if you're working for a well-funded startup that has a 3 year plan and is fairly set on where it's going, it might be good to make precautions a few months ahead of time.

If it's a personal project, you probably don't need all those bells and whistles - it's better to focus on core functionality.

And the reasonings here can be flipped - This is generally what good CTOs and Senior Developers can spot. It really comes down to the needs of the business/project.

It's also good to write your code in a modularized way where you aren't forced to write functionality in pre-requirement. It might be a "Code Smell" if you're having to write precautionary code for something that's coming months down the line.

Dependency Inversion

Real World Example
Imagine there are two banks - "Bank A" and "Bank B"

In order to withdraw money from Bank A, you put your card into an ATM, enter your pin and you're then presented with a terminal/command line logged into a MySQL server. From here, you have to write an update query to deduct money from your bank balance - the machine then gives you your money.

In order to withdraw money from Bank B, you put your card into an ATM, enter your pin, enter the money you want on the pin pad and the machine gives you your money.

The first one violates this principle, the second one doesn't (you might have guessed...)

In Programming Terms
The key thing to understand is that your classes and functions shouldn't know anything about their dependencies.

This leads to something called "Tight Coupling" where if you want to switch out your dependencies for different ones, it becomes a pain and you have to effectively re-write everything that uses it.

Like in the real world example, if Bank A decided to go from MySQL to MongoDB, all of its customers now have to learn how to write Mongo queries.

In the programming world, if your "ShopModel" can only work with a "MySQLConnection", if you suddenly switch to a Mongo-based architecture, the other 40 models that use that connection now need to change to a "MongoConnection"

Instead they should use a "DBConnection" interface (something that defines what all database connections look like) and a container of some sort should give out the current instance of that. This makes changing things down the line a lot easier

DRY (Don't Repeat Yourself)

Real World Example
Imagine there are two Social Media Agencies - Agency A and Agency B

When Agency A hires a new social media manager on the team, the manager learns the social media strategy by looking at the other managers in the team and copying their process.

If the boss at Agency A wants to make a change to the process, he'll sit down with each one and tell them about the changes. Sometimes he forgets to tell one or two managers and that means they're executing on redundant processes.

When Agency B hires a new social media manager on the team, the manager learns by reading a single google document that everyone has access to.

If the boss at Agency B wants to make a change to the process, he'll make a change in the google document and tag everyone in the Slack channel to read the changes. This means he's updated everyone in one shot.

Agency A violates DRY and Agency B adheres to it.

In Programming Terms
If you find yourself writing a code that does the same thing over and over again, you might want to put that functionality into a re-usable class, method or function in your application.

This isn't always the case, and there's actually mixed opinion as to when you should and shouldn't do this, but as a new developer it's really good to begin thinking about where you can make code re-usable. You'll get the nuances down the line, and this will come particularly when you work with other experienced developers.

Single Responsibility Principle

Real World Example
Phil is a graphic designer. His boss wants him to also manage the social media account, babysit his dog when he plays golf, help stock the shelves and milk the cows.

Phil has too much responsibility; you might say he violates the Single Responsibility Principle.

It's his bosses fault though, he should have hired specialists for each of these responsibilities. That's adhering to the Single Responsibility Principle

In Programming Terms
Whether you're a functional or an OOP programmer, you'll be building "pieces of functionality" into your application - whether it's functions, classes or any other symbol of execution.

If you try and describe the responsibilities that your little slice of code has and you come up with more than 1-2 points, you're probably violating SRP.

FYI: This is a line that becomes clearer with experience, but a way to shortcut your learning of this is by looking at major open source repositories and trying to explain what you think the responsibilities of each file/class etc is and you will start to spot the pattern of where people begin to separate things out.

Give us some other programming principles you want simplified, or tell us to do better on these 4 if you still can't get them

We really want to try and help everyone get access to these "mid-level developer principles" - because they don't have to be mid-level if someone can provide the write explanation.

• What are some other principles you find hard to understand?
• Which ones did we not explain well enough in this post?

Thanks for your feedback and helping us curate content that you'll find useful!

Any other programming design patterns you find hard to understand?

Let us know in the discussion below, this is the first post in our “Programming Principles for Dummies” series and we want to make as many of them as accessible to beginners as possible. Because it enables us to write better code!

Curious about frontend development? We’ve just released a free crash course (No, it’s really free - no upgrades, no hidden costs)

We worked for a couple of months on a professional design and 4 hours 20 minutes of video content to bring you our free crash course showing you how to code this portfolio website (which we constantly encourage you to customise to your own style)

If that’s something that would interest you, and you’d like to learn more about HTML, CSS, SCSS, Bootstrap 4, Git, GitHub Pages and a sprinkle of JavaScript and jQuery, you can register today, for free, from this link here.