As I already talked that patterns are created over the years of software evolution. Let's discuss what are those? Software Design Principles are the building blocks of creating robust, maintainable and scalable software systems. Software engineers adhere to design principles to create software applications that satisfy both user needs and technological requirements, just as architects follow blueprints when creating structures. We'll look at the fundamental principles of software design that inform the creation of high-quality software in this blog article.
What are software design principles/patterns?
Software design principles are a set of guidelines, concepts, and best practices that help engineers make informed decisions during the design phase of a software project. By strengthening the structure, modularity, and maintainability of software, these guidelines seek to raise its overall quality.
Here are the most famous design principles -
1. SOLID Principles
This is an acronyms for set of 5 essential principles of Object Oriented Design but as solid as name.
- Single Responsibility
A class should have only one reason to change, meaning it should have a single, well defined responsibility. For example a class to fetch data should only fetch data and should not responsible to render or modify data.
- Open/Closed Principle (OCP)
Software entities (classes, modules, functions) should be open for extension but closed for modification. This is promoting the use of interfaces and inheritance.
- Liskov Substitution Principle (LSP)
Subtypes should be substitutable for their base types, ensuring that derived classes do not violate the behavior expected from their base class.
- Interface Segregation Principle (ISP)
Clients should not be forced to depend on interfaces they do not use, encouraging the creation of small, specific interfaces. In other words, no code should be forced to depend on methods it does not use. Meaning client should know only the method they use.
- Dependency Inversion Principle (DIP)
High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. In simple words "It's like focusing on what something does, not how it does it, making your code more adaptable and less tightly coupled."
DRY (Don't Repeat Yourself)
You should create methods/class if you think this same logic is going to be use again. If the logic is already written and you are going to use that change it to a function and the call the function at both places.
KISS (Keep is Stupid Simple) [Most favourite one]
Keep it simplest, keeping in mind that a new intern in your team joining after 2 years can read, understand and modify your solution without help.
You are writing for fellow developers, compiler can understand your code anyways.
YAGNI (You Ain't Gonna Need It)
You should avoid adding functionality unless it is actually needed, as prematurely adding functionality, optimisations and features can lead to unnecessary complexity and maintenance overhead. So write your code wisely.
Separation of Concerns
You should breakdown your software into distinct, manageable parts, each responsible for a specific aspect of functionality. This improves code organisation, readability and maintainability.
Why are Software Design Principles Important?
Using these principles while designing softwares, writing and reviewing codes adds many benefits to your software a few of them are listed below.
- Improved maintainability: Well-designed software is easier to maintain and update because changes are isolated and predictable.
- Enhanced Scalability: Modular and loosely coupled designs allow for easier scaling of software systems.
- Reduced Bugs: Design principles help catch design flaws early in the development process, reducing the likelihood of bugs and defects.
- Code Reusability: Reusable components simplify development and reduce duplication of effort eventually speedup the development process as your codebase grows.
- Better Collaboration: Consistent design principles make it easier for teams to work together on large projects. Maintaining proper design logs will help faster onboarding for newer developers in team.
In my opinion adding software design principles to your software is not a good to have but a must have feature, in start you might feel this is adding extra efforts but along with the time when your codebase and team size grows this will start showing that how economic your decision was. As you gain experience in software design you will realise that using these principle became your second nature, guiding you toward elegant and effective solutions to complex problems.
In future blog posts we will look for another design principles or go deeper in above mentioned if needed. Keep me posting what else you want to know, I will try my best to resolve your doubts.
Till the next time keep Learning-Coding-and-Growing.
Next Article: Mastering the Art of Software Design: An Overture to Object-Oriented Design
Top comments (3)
Are you sure about "KISS (Keep is Stupid Simple)"? Doesn't even makes sense.
It's Keep It Simple Stupid, despite many shy snowflakes trying to make something else of it.
en.m.wikipedia.org/wiki/KISS_princ...
RTFM is Read The F..king Manual, also an advice to take by everyone, especially those who think that copying code snippets from web and ChatGPT will really solve the tasks.
I didn't know the real origin of this term, but I have changed this to "KISS (Keep is Stupid Simple)" because I don't want to call that person stupid, who is just learning coding and not have much experience. Eventually they will grow and develop the level of understanding. Despite in Navy they might have different analogy.
RTFM is needed in case only if the person is unable to understand why that piece of code was written that way and how is it solving the problem. Otherwise it is just saving time in typing the code.
Best is to write it on your own, that would be most tailored and efficient solution to your problem.
SOLID, YAGNI, KISS, RTFM, design patterns and best practices in general are not specific to people without experience, they are equally important and recommended for seniors and directors too. The end user doesn't care who created the product, they just want something that works. Same goes for management, they don't care if the developer is junior or senior, they want code that is easy to maintain, debug, extend and is error free. Limiting these principles or this article to juniors would be a huge mistake, don't assume all seniors are seniors because of their knowledge.
RTFM is needed for everyone at some point (more when learning something new, less in later phases - again, not related to age or seniority). It's not primarily about understanding, one can't write optimal code (not even good code in some cases) if they don't know the programming language, the libraries, APIs and all other components they are using. Optimal code starts from the syntax and continues with chosing the right components for the problem i.e. using an array vs list can have significant difference in performance with large number of items (in some environments 2k+ is already large), and in some cases the development framework (i.e. Angular vs React vs Vue) or programming language.
Or do you have any idea how many applications are slow and struggle with resources (i.e. memory) because the developer doesn't read the documentation and instead of paging they request all entities from the database? It may not be a problem on a developer PC but it will cripple cheap consumer laptops, not to mention mobile devices.