- Single Responsibility Principle (SRP): A class should have only one reason to change. This means that a class should be responsible for only one thing. If a class has too many responsibilities, it becomes difficult to change and maintain.
- Open/Closed Principle (OCP): A class should be open for extension, but closed for modification. This means that you should be able to extend the behavior of a class without modifying its source code.
- Liskov Substitution Principle (LSP): Objects of a superclass should be able to be replaced with objects of a subclass without affecting the correctness of the program. This means that you should be able to use any subclass in place of its superclass without breaking the code.
- Interface Segregation Principle (ISP): Clients should not be forced to depend on methods they do not use. This means that an interface should be split into smaller interfaces that are more specific to the needs of the clients.
- Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Instead, they should both depend on abstractions. This means that you should not depend on concrete implementations, but rather on abstractions.
- Don’t Repeat Yourself (DRY): This principle states that every piece of knowledge or logic should have a single, unambiguous representation in the system. This means that you should avoid duplicating code or logic, as this makes the code harder to maintain.
- Keep It Simple, Stupid (KISS): This principle states that you should keep your code as simple as possible. This means that you should avoid unnecessary complexity and keep the code easy to read and understand.
- You Ain’t Gonna Need It (YAGNI): This principle states that you should not add functionality until it is actually needed. This means that you should avoid adding code that is not required at the moment, as it adds unnecessary complexity to the system.
- Single Level of Abstraction (SLA): This principle states that you should have a single level of abstraction in your code. This means that you should avoid mixing different levels of abstraction, as it makes the code harder to read and understand.
- Law of Demeter (LoD): This principle states that a module should not know about the internal workings of the objects it uses. This means that you should avoid calling methods on objects that are not directly related to your code.
These principles are meant to guide developers in writing code that is easy to read, understand, and maintain. While there is some debate about the effectiveness of these principles, they are widely accepted as good practices in the software development community.
