Skip to content

tranviethuy01/SOLID-for-GO

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 
 
 

Repository files navigation

SOLID for GO Development

This repository is code that i use to demonstrate how to apply SOLID Principle in GO Development

Basic understanding for SOLID Principle

The SOLID principles are a set of five design principles that, when followed, lead to more maintainable and scalable software. The SOLID principles are:

  1. Single Responsibility Principle (SRP):

    • A class should have only one reason to change, meaning it should have only one responsibility.
    • This principle encourages the organization of code into small, focused, and modular units, each responsible for a single aspect of the system.
  2. Open/Closed Principle (OCP):

    • Software entities (classes, modules, functions) should be open for extension but closed for modification.
    • This principle promotes the idea that you should be able to extend the behavior of a system without modifying existing code. New features should be added through the introduction of new code, not by changing existing code.
  3. Liskov Substitution Principle (LSP):

    • Subtypes must be substitutable for their base types without altering the correctness of the program.
    • In other words, objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. This ensures that derived classes can be used interchangeably with their base classes.
  4. Interface Segregation Principle (ISP):

    • A class should not be forced to implement interfaces it does not use.
    • This principle suggests that it is better to have several small, specific interfaces rather than a large, general-purpose interface. Classes should only be required to implement the methods that are relevant to their behavior.
  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.
    • This principle advocates the use of abstractions (like interfaces or abstract classes) to decouple high-level modules from low-level modules, promoting flexibility and ease of maintenance.

By adhering to these principles, developers can create code that is more modular, flexible, and easier to maintain and extend over time. Each principle addresses a different aspect of software design and contributes to the overall goal of building robust and scalable systems.

Further Contact

For further contact, contact me via

Email: [email protected]

LinkedIn: https://www.linkedin.com/in/tranviethuy/

My Blog: https://tranhuy.bachkhoasaigon.com/

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages