Understand Software Design Principles

Photo by Ben Kolde on Unsplash

In this post, I am going to discuss some common design principles that we should use while developing or architecting an application.

DRY
KISS
YAGNI
SOLID

We will discuss each of these in detail.

DRY (Don’t Repeat Yourself):

• DRY is a software development principle aimed at reducing the repetition of code and promoting code reuse.
• It emphasizes that each piece of knowledge or logic should have a single, unambiguous representation within a system.
• By following the DRY principle, developers can avoid duplication, which reduces the risk of inconsistencies and makes code easier to maintain and modify.
• Example: Instead of copying and pasting the same code block in multiple places, refactor it into a reusable function or method that can be called whenever needed.
• DRY we can achieve by trying to add Util classes and methods, try to extract repeated code as a method and use it in every place. It will help if we are modifying some piece of code we don’t need to modify at all places instead of just in one place.

KISS (Keep It Simple, Stupid):

• KISS is a design principle that encourages keeping systems, designs, and solutions as simple as possible.
• It suggests that simplicity should be preferred over complexity, and unnecessary complexity should be avoided.
• KISS advocates for straightforward and understandable solutions that are easier to implement, maintain, and debug.
• Example: Instead of adding layers of abstraction and complexity to a solution, opt for a simpler approach that fulfils the requirements without unnecessary overhead.

YAGNI (You Aren’t Gonna Need It):

• YAGNI is a principle that advises against adding functionality to a system until it is necessary.
• It discourages developers from implementing features based on speculative future requirements or over-engineering solutions.
• YAGNI promotes a lean and agile approach to development, where features are added incrementally as needed, rather than preemptively.
• Example: Instead of implementing a wide range of features upfront, focus on delivering the minimum viable product (MVP) and iteratively adding features based on user feedback and evolving requirements.

SOLID

The SOLID principles are a set of five design principles that help software developers design maintainable and scalable object-oriented systems. Each principle focuses on a specific aspect of software design, promoting loose coupling, high cohesion, and flexibility in the codebase. Here’s a brief overview of each principle:

1. Single Responsibility Principle (SRP):

• A class should have only one reason to change.
• It states that a class should have only one responsibility or job, meaning that it should only have one reason to be modified.
• This principle encourages smaller, more focused classes, which are easier to understand, test, and maintain.

2. Open/Closed Principle (OCP):

• Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
• It encourages the design of software components that can be extended or customized without altering their source code.
• By relying on abstractions and interfaces, new functionality can be added through inheritance or composition, without modifying existing code.

3. Liskov Substitution Principle (LSP):

• Subtypes must be substitutable for their base types without affecting the correctness of the program.
• It ensures that objects of a superclass can be replaced with objects of its subclasses without altering the correctness of the program.
• Violations of this principle can lead to unexpected behavior and errors, especially in polymorphic code.

4. Interface Segregation Principle (ISP):

• Clients should not be forced to depend on interfaces they do not use.
• It suggests that classes should not be forced to implement interfaces that contain methods they do not need.
• Instead of creating large, monolithic interfaces, it’s better to define smaller, more specific interfaces tailored to the needs of individual clients.

5. 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.
• It encourages decoupling between modules by introducing abstractions (interfaces, abstract classes) that define the interactions between them.
• By depending on abstractions rather than concrete implementations, the system becomes more flexible and easier to maintain.

By adhering to these principles, developers can create software that is easier to understand, maintain, and extend, leading to better overall quality and scalability.

These Principles are useful to know while developing an application, or adding functionality to existing applications.