Update README.md

Author: eleev

README.md

@@ -171,31 +171,40 @@ The following patterns are not part of the `design patterns` topic. However, the
 ## Software Design Principles
 There are numerous software design principles that help to create maintainable, scalable, and efficient software systems. These principles, along with other best practices, can guide developers in creating high-quality software systems that are easy to understand, maintain, and extend.
 
-1. SOLID Principles:
- 1. Single Responsibility Principle (SRP): A class should have only one reason to change, which means it should have only one responsibility.
- 2. Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification.
- 3. Liskov Substitution Principle (LSP): Subtypes should be substitutable for their base types without altering the correctness of the program.
- 4. Interface Segregation Principle (ISP): Clients should not be forced to implement interfaces they don't use; instead, create specific interfaces for each client.
- 5. Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions.
-2. DRY (Don't Repeat Yourself): Avoid duplicating code and functionality; aim for modularity and reusability.
-3. KISS (Keep It Simple, Stupid): Design should be as simple as possible, and complexity should be avoided whenever possible.
-4. YAGNI (You Aren't Gonna Need It): Do not implement features or functionality until they are actually needed, as it can lead to unnecessary complexity.
-5. Separation of Concerns (SoC): Divide your application into distinct sections, each with a specific responsibility, to improve maintainability and modularity.
-6. Encapsulation: Bundle data and the methods that operate on that data within a single unit, thereby hiding the internal state and implementation details from other parts of the system.
-7. Composition over Inheritance: Favor object composition over class inheritance to promote flexibility and avoid issues related to deep inheritance hierarchies.
-8. Law of Demeter (LoD) / Principle of Least Knowledge: An object should only communicate with its immediate neighbors and should not have knowledge of the inner workings of other objects.
-9. Principle of Proximity: Related code and functionality should be placed close together, promoting cohesion and making it easier to understand the relationships between components.
-10. Fail-Fast: Design the system to fail as soon as possible when something goes wrong, making it easier to identify and fix problems.
+1. `SOLID` Principles:
+ - `Single Responsibility` Principle (SRP): A class should have only one reason to change, which means it should have only one responsibility.
+ - `Open/Closed` Principle (OCP): Software entities should be open for extension but closed for modification.
+ - `Liskov Substitution` Principle (LSP): Subtypes should be substitutable for their base types without altering the correctness of the program.
+ - `Interface Segregation` Principle (ISP): Clients should not be forced to implement interfaces they don't use; instead, create specific interfaces for each client.
+ - `Dependency Inversion` Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions.
+2. `DRY` (Don't Repeat Yourself): Avoid duplicating code and functionality; aim for modularity and reusability.
+3. `KISS` (Keep It Simple, Stupid): Design should be as simple as possible, and complexity should be avoided whenever possible.
+4. `YAGNI` (You Aren't Gonna Need It): Do not implement features or functionality until they are actually needed, as it can lead to unnecessary complexity.
+5. `Separation of Concerns` (SoC): Divide your application into distinct sections, each with a specific responsibility, to improve maintainability and modularity.
+6. `Encapsulation`: Bundle data and the methods that operate on that data within a single unit, thereby hiding the internal state and implementation details from other parts of the system.
+7. `Composition over Inheritance`: Favor object composition over class inheritance to promote flexibility and avoid issues related to deep inheritance hierarchies.
+8. `Law of Demeter` (LoD) / Principle of Least Knowledge: An object should only communicate with its immediate neighbors and should not have knowledge of the inner workings of other objects.
+9. `Principle of Proximity`: Related code and functionality should be placed close together, promoting cohesion and making it easier to understand the relationships between components.
+10. `Fail-Fast`: Design the system to fail as soon as possible when something goes wrong, making it easier to identify and fix problems.
 11. `GRASP` (General Responsibility Assignment Software Patterns):
- 1. `Information Expert`: Assign a responsibility to the class that has the necessary information.
- 2. `Creator`: Assign the responsibility of creating an object to the class that uses it the most or has the necessary information to create it.
- 3. `Controller`: Assign the responsibility of handling external events to a specific class, often referred to as a controller.
- 4. `Low Coupling`: Minimize dependencies between classes to promote modularity and ease of maintenance.
- 5. `High Cohesion`: Keep related responsibilities within the same class, making the class easier to understand and maintain.
- 6. `Polymorphism`: Use inheritance and interfaces to create flexible and reusable solutions.
- 7. `Pure Fabrication`: Create artificial classes to achieve low coupling and high cohesion when necessary.
- 8. `Indirection`: Introduce an intermediate class to manage relationships between other classes, reducing coupling.
- 9. `Protected Variations`: Identify points of potential variation and create stable interfaces around them to minimize the impact of changes.
+ - `Information Expert`: Assign a responsibility to the class that has the necessary information.
+ - `Creator`: Assign the responsibility of creating an object to the class that uses it the most or has the necessary information to create it.
+ - `Controller`: Assign the responsibility of handling external events to a specific class, often referred to as a controller.
+ - `Low Coupling`: Minimize dependencies between classes to promote modularity and ease of maintenance.
+ - `High Cohesion`: Keep related responsibilities within the same class, making the class easier to understand and maintain.
+ - `Polymorphism`: Use inheritance and interfaces to create flexible and reusable solutions.
+ - `Pure Fabrication`: Create artificial classes to achieve low coupling and high cohesion when necessary.
+ - `Indirection`: Introduce an intermediate class to manage relationships between other classes, reducing coupling.
+ - `Protected Variations`: Identify points of potential variation and create stable interfaces around them to minimize the impact of changes.
+12. `Convention Over Configuration`: Establish sensible defaults and conventions to minimize the amount of configuration required, making it easier for developers to work with the system.
+13. `Code Reuse`: Reuse existing code, libraries, or frameworks instead of reinventing the wheel. This saves time and effort and often results in more stable and efficient solutions.
+14. `Incremental Development`: Develop and deliver software in small, manageable increments, allowing for rapid feedback and adjustment.
+15. `Test-Driven Development` (TDD): Write tests before writing the actual code, ensuring that code meets the desired specifications and improving the overall quality of the software.
+16. `Continuous Integration` (CI) and Continuous Delivery (CD): Integrate code changes frequently and automatically, and deploy updates to production with minimal human intervention. This promotes rapid feedback and reduces the risk of introducing errors.
+17. `Principle of Least Astonishment`: Design the software so that its behavior is predictable and intuitive, minimizing surprises for users and developers.
+18. `Scalability`: Design the system to handle increased workload efficiently by adding more resources or optimizing resource utilization.
+19. `Modularity`: Break down a complex system into smaller, manageable modules that can be developed, tested, and maintained independently.
+20. `Maintainability`: Design the software to be easy to understand, modify, and extend, allowing for efficient long-term maintenance.
 
 
 # 📝 References