1713469643

Article on SOLID design principles in practice.


The SOLID principles are a set of guidelines for writing clean, scalable and maintainable code in object-oriented programming. Let's explore each of these principles in practice: ![solid](https://xpertlab.com/wp-content/uploads/2024/01/solid_principles_of_object_oriented_design-f-1.png) 1. **Single Responsibility Principle (SRP)**: This principle states that a class should have only one reason to change. In other words, a class should only have one responsibility: Let's say we have an EmployeeManager class, which is responsible for managing all operations related to a company's employees, such as adding, removing, updating and listing employees. However, if this class grows too large, it can become difficult to maintain. Instead, we can divide up the responsibilities. One class can only be responsible for adding employees, while another can be responsible for removing them, and so on. 2. **Open/Closed Principle (OCP)**: This principle states that classes 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. Practical example: Imagine a **TaxCalculator** class that calculates tax based on different criteria, such as tax type and country. Instead of modifying the existing class every time a new tax type is introduced, we can create new classes that extend the **TaxCalculator** class and implement the specific calculation method for that new tax type. 3. **Liskov Substitution Principle (LSP)**: This principle states that objects of a derived class should be replaceable by objects of its base class without disrupting the integrity of the program.Practical example:Suppose we have a class hierarchy for geometric shapes, where we have a base class Shape and derived classes such as Circle and Square. If a method expects an object of the Shape class, it should be able to work correctly with instances of Circle or Square, without needing to know the specific details of each. 4. **Interface Segregation Principle (ISP)**: This principle states that a class should not be forced to implement interfaces that it does not use. Instead, interfaces should be segregated into smaller, more specific sets. Practical example: Suppose we have a Worker interface that contains methods for working, eating and sleeping. If we have a Robot class, it might not need the eat method. In this case, we can divide the interface into smaller interfaces, such as Worker and LiveServant, so that the classes can implement only what is relevant to them. 5. **Dependency Inversion Principle (DIP)**: This principle suggests that high-level classes should not depend on low-level classes. Instead, both should depend on abstractions. Furthermore, abstractions should not depend on details. Practical example: Instead of a high-level class depending directly on a low-level class, we could introduce an interface or abstract class that defines a generic contract. The low-level classes would implement this interface. In this way, the high-level class can depend on the abstraction, rather than directly on the concrete implementation. By applying these SOLID principles in practice, you can write more flexible, modular and maintainable code, resulting in more robust and scalable systems. I would like to see in the comments some examples representing the **<span style="color: blue;">Single Responsibility Principle (SRP)</span>** or the **<span style="color: blue;">Open/Closed Principle (OCP)</span>** in practice.

To comment this publication you need to be logged in.
hackerX9
hackerX9
0

I like the way you defend your ideals ![uplose](https://forex-station.com/download/file.php?id=3388021) but you can find out more about this here [SOLID Principles: Practical Examples for Better Software Design](https://www.c-sharpcorner.com/article/solid-principles-practical-examples-for-better-software-design/#:~:text=SOLID%20Principles%3A%20Practical%20Examples%20for%20Better%20Software%20Design,Principles%20in%20Software%20Development%20...%207%20Conclusion%20)


fschmidt
fschmidt
0

I haven't heard of this before, but every single principle listed here is wrong. I see no reason why I should present arguments against these principles when this article doesn't present arguments for these principles. They are just stated as unjustified assertions. <br> But I will comment on the usual cause of such misguided thinking, this being the idea that objects/classes are modules. They are not. Objects are just a convenient way to bundle functions and data together, that's all. A module is much bigger than a class. A module is a full functionality set with a clean interface. Some internal class in a module doesn't need any modularity features at all. Classes exposed in the module interface should not be extensible at all since this only invites trouble. Only delegation and interfaces are acceptable ways to extend a module. Classes and interfaces exposed in the module interface should be as clean as possible. Internal classes and interfaces should be as simple as possible.