Design Concepts Every Developer Should Know
What does Design Concept/Principle mean for a developer?
- What is good software design concept? How would you measure it? What practices would you need to follow to achieve it? How can you make your architecture flexible, stable and easy to understand?
- These are the great questions; but, unfortunately, the answers are different depending on the type of application you’re building. Nevertheless, there are several universal principles of software design that might help you answer these questions for your own project. Here I will show you seven of universal Design Concepts.
Here I have used javascript for examples but you can relate with most of the languages.
1. DRY — Do Not Repeat Yourself
DRY refers to code writing methodology. DRY usually refers to code duplication. If we write the same logic more than once, we should “DRY up our code.”
A common way to DRY up code is to wrap our duplicated logic with a function and replace all places it appears with function calls.
2. KISS — Keep It Simple Stupid
Keeping it simple many times harder than you think. Usually when someone tries to overthink and over-analyse a soluiton to a problem. For example an Architect suggests creating a Microservice framework for a simple website. The Engineer will then say: “Let’s KISS it and do something simpler”.
Another rule of thumb is whenever you think to yourself to use something extraordinary that you’ve learned, you should probably apply KISS it.
3. YAGNI — You Ain’t Gonna Need It
A cousin of KISS. Keeping it simple is not adding modules, frameworks and dependencies we don’t actually need.
Let’s think that you are working on a simple prototype to show to a client that is just for showcase purpose.
You decide to develop it in React because you like front end framework like this and want to go for SPA. You then find yourself comparing flux implementations for state management, and deciding to go with Redux. You will also need webpack to process JSX for React, don’t you?.
You decide to setup a small nodejs server to serve your files. You add Socket.IO just in case you’ll need real-time notifications for whatever reason.
You finish your prototype, which turned out to be a glorified web page to show a concept to your product manager. You later find out your product manager took a screenshot of the page and put it on a slide.🙃
Now, you may think that did I really need React+Redux+Node+Socket.IO to showcase just a simple prototype screenshot ??? 🙄 You don’t, right!!!
So, don’t overpower your product if YAGNI, as simple as that.
4. SLAP — Single Level of Abstraction Principle
SOC — Separation of Concerns
“do one thing well”
It refers the way you should organize your code (functions to be specific) to keep it maintainable.
Your functions should do only one thing, or, with the SLAP in mind, should have only a single level of abstraction. Basically, a function that, for example, reads the user input, shouldn’t also process it. Instead, it’ll use a separate function, which is on the other, lower level of abstraction. The more general the function is and the more other functions it utilizes, the higher it is in the abstraction hierarchy.
5. TDD — Test Driven Development
TDD can be summed in 4 steps:
1 Decide on the desired functionality
2 Create the test for that functionality first. The test fails since no code exists yet.
3 Write the code that implements the desired functionality. The test now passes.
4 Repeat.
6. BDUF — Big Design Up Front
BDUF is here to remind us not get over carried with super complex architecture. Start small and iterate.
BDUF is basically what happens when you don’t KISS and end up with a lot of stuff which YAGNI.
7. SOLID Principles
This is combination of five principles
Single Responsibility Principle
It is simillar to SLAP or SOC to make sure “do onw thing and do it well” concept.
Open-Closed Principle
Open-Closed Principle means our modules should be open to extension, but closed to modification. Meaning that if someone wants to extend our module’s behavior, they won’t need to modify existing code if they don’t want to.
Liskov Substitution Principle
LSP is a concept in Object Oriented Programming that states: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
— In programming, the LSP states that if S is a subtype of T, then objects of type T may be replaced (or substituted) with objects of type S.
— In short, it states that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
— See below example how createPost() has been implemented such that it doesn’t violate this principle.
Interface Segregation Prinicple
ISP refers to segregation in your code. In simple way, don’t add additional functionality to an existing interface by adding new methods.
Javascript doesn’t have interfaces. You can relate below example with typescript.
Dependency Inversion Principle
You must have heard “Dependency Injection” somewhere and this principle is simillar to that.
Your code should not have dependecy in it.
Here in example, you can see that first code depends on dispatcher object and second code has that dependency removed.
CHEAT-SHEET →
