SOLID principles for software development

SOLID principles are five design guidelines for writing clean, maintainable, and scalable object-oriented software. The acronym stands for:


  1. S - Single Responsibility Principle (SRP):
    A class should have one and only one reason to change.

  2. O - Open/Closed Principle (OCP):
    Software entities should be open for extension but closed for modification.

  3. L - Liskov Substitution Principle (LSP):
    Subtypes must be substitutable for their base types.

  4. I - Interface Segregation Principle (ISP):
    No client should be forced to depend on methods it does not use.

  5. D - Dependency Inversion Principle (DIP):
    Depend on abstractions, not on concrete implementations.



1. Single Responsibility Principle (SRP)

  • Definition: A class should only have one responsibility or reason to change.
  • Why? Simplifies maintenance and avoids unintended side effects when modifying code.
  • Example:
    • Bad: A class managing both user authentication and database operations.
    • Good: Separate classes for authentication and database operations.


2. Open/Closed Principle (OCP)

  • Definition: Classes should be open for extension but closed for modification.
  • Why? Avoids altering existing code, reducing the risk of bugs.
  • Example:
    • Bad: Adding features by editing existing class methods.
    • Good: Add new features by extending the class or implementing new functionality.


3. Liskov Substitution Principle (LSP)

  • Definition: Subclasses should be replaceable by their base class without breaking functionality.
  • Why? Ensures robust polymorphism and predictable behavior.
  • Example:
    • Bad: A subclass that overrides a method with completely different logic.
    • Good: Subclasses that enhance or maintain behavior of the parent class.


4. Interface Segregation Principle (ISP)

  • Definition: Interfaces should be specific to client needs; no client should depend on irrelevant methods.
  • Why? Prevents bloated interfaces and unused functionality.
  • Example:
    • Bad: One large interface with methods unrelated to some clients.
    • Good: Multiple smaller, specific interfaces for different client requirements.


5. Dependency Inversion Principle (DIP)

  • Definition: High-level modules should depend on abstractions, not on concrete implementations.
  • Why? Promotes flexibility and decouples systems for easier testing and scaling.
  • Example:
    • Bad: A class directly instantiating and depending on a specific implementation.
    • Good: Use interfaces or abstractions so dependencies can be swapped easily.





Comments

Post a Comment

Write something to CodeWithAbdur!

Popular posts from this blog

Quotation marks to wrap an element in HTML

In HTML, quotation marks can be used to wrap an element, providing visual emphasis and indicating that the enclosed content represents a quotation.  This styling technique enhances the presentation of quoted text on web pages. Setting default quotation marks: To set quotation marks to wrap an element in HTML, you can use the `quotes` CSS property along with the `content` property to specify the quotation marks to be used (the below example uses the default quotes value, so it is not mentioned as can be seen). Here's how it can be achieved: /* Define the quotation marks */ .q:before { content: open-quote; } .q:after { content: close-quote; } In this CSS: - `open-quote` represents the opening quotation mark. - `close-quote` represents the closing quotation mark. Now, you can apply the `.q` class to elements where you want to set quotation marks: <p class="q">This is a quoted text.</p> This will render as: “ This is a quoted...
Read more

What is the difference between iostream and iostream.h in cpp?

In C++, there are two seemingly similar headers for input/output operations: iostream and iostream.h. However, they have key differences you should be aware of: 1. Standard vs. Non-Standard: **iostream** is the standard header for input/output operations in C++. It is part of the C++ Standard Library and is guaranteed to be available and consistent across different compilers. **iostream.h** is a non-standard header . It was used in pre-standard C++ and some early compilers. It is not part of the C++ Standard Library and its availability and behavior might vary depending on the compiler. 2. Namespace: **iostream** defines everything within the **std** namespace. This helps avoid naming conflicts with other libraries or user-defined functions. **iostream.h** does not use namespaces. This means all its elements are directly available in the global namespace, which can lead to potential naming conflicts and is generally considered less modern practice. 3. Recommendations: Always use iostr...
Read more

The Basic Structure of a Full-Stack Web App

A basic structure of a full-stack web application typically consists of three main components: the front end, the back end, and the database.  Each component serves a specific role in the application's architecture. Here's an overview of the basic structure: Front End: The front end is the user-facing part of the application that users interact with directly. It's responsible for presenting data to users, collecting user input, and providing a user-friendly interface. Common technologies used in the front end include HTML, CSS, and JavaScript. Front-end frameworks and libraries like React, Angular, or Vue.js are often used to build interactive and dynamic user interfaces. Basic Components of the Front End: User Interface (UI) Components User Input Forms Display of Data Interaction Logic (JavaScript) Back End: The back end is the server-side portion of the application responsible for handling business logic, data processing, and serving data to the front end. It communicates...
Read more