![\"\"](\"https:\/\/mmmake.com\/wp-content\/uploads\/2025\/04\/S.svg\")
\n <\/div>\n \n ![\"\"](\"https:\/\/mmmake.com\/wp-content\/uploads\/2025\/04\/O.svg\")
\n <\/div>\n \n ![\"\"](\"https:\/\/mmmake.com\/wp-content\/uploads\/2025\/04\/L.svg\")
\n <\/div>\n \n ![\"\"](\"https:\/\/mmmake.com\/wp-content\/uploads\/2025\/04\/I.svg\")
\n <\/div>\n \n ![\"\"](\"https:\/\/mmmake.com\/wp-content\/uploads\/2025\/04\/D.svg\")
\n <\/div>\n \n A class should only have one responsibility and there should only be one reason why you want to change the class. Do one thing and do it well! The result is an architecture that is clear, understandable and easier to maintain. If the single responsibility principle is not followed, potential maintenance problems are created in the software. This can have a negative impact on other areas and functionalities.<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Single Responsibility Principle:<\/h3>\n\n\n- Easy maintenance: Since you define a clear purpose for each class, it is easier to maintain because it is smaller and clearer <\/li>\n\n\n\n
- Avoidance of side effects in relation to other responsibilities in the event of changes <\/li>\n\n\n\n
- Better collaboration: The work in programming teams can be better divided, because each programmer can then work on a class for which he\/she is responsible. <\/li>\n\n\n\n
- Keeps dependencies to a minimum when reusing classes <\/li>\n\n\n\n
- Small classes greatly simplify troubleshooting <\/li>\n\n\n\n
- Possibility to assign clear and meaningful class names, as each class has a responsibility <\/li>\n\n\n\n
- Decoupling implementations based on what is likely to change together<\/li>\n\n\n\n
- Development and testing costs are reduced <\/li>\n<\/ul>\n\n
Open Closed Principle<\/h2>\n\nModules should be open for extensions, but closed for modification (changes)<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
Basically, the Open Closed Principle is about taking a strategic approach, because it requires that written code (which has also been tested) should no longer be changed or that the software design should be constructed in such a way that changes can be supported without having to completely rebuild the system.
\nHow can this be achieved? Through inheritance or by providing the module with an interface. This does not change the existing behavior of the module, but merely extends it with additional functions or data.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n 
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Open Closed Principle: <\/h3>\n\n\n- Errors are avoided because code that has already been written is left alone <\/li>\n\n\n\n
- Software becomes more maintainable <\/li>\n\n\n\n
- Reuse through the design of stable interfaces <\/li>\n<\/ul>\n\n
Liskov Substitution Principle<\/h2>\n\nIf a derived class is to be implemented, the base class must be extended without changing the behavior of the base function<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
To put it simply: subclasses must behave like base classes. The Liskov Substitution Principle is actually a substitutability principle. This is about interchangeability across class inheritance hierarchies: subclasses must behave like base classes. Look at the graphic with the square and the rectangle: There is a relationship between squares and rectangles: you can say every square is a rectangle, but not every rectangle is a square. As you can see, this inheritance relationship would not work in programming.<\/p>\n
<\/p>\n
So how can you solve this in programming? Instead of the inheritance of square and rectangle, a third class is introduced from which both square and rectangle are derived. This means that the square and rectangle are only linked via the new third class.<\/p>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n 
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantage of the Liskov Substitution Principle:<\/h3>\n\n
Security that an implementation can be replaced without changing its behavior<\/p>\n\n
Interface Segregation Principle<\/h2>\n\nEach class should be focused on one aspect or topic only<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The Interface Segregation Principle deals with the separation or decoupling of classes. With the Open Closed Principle, we have learned to work with interfaces. However, interfaces are not without problems either, as they usually tend to get bigger and bigger. As a result, it is becoming increasingly difficult to provide a complete implementation, as more and more code has to be added.<\/p>\n
<\/p>\n
The solution? interfaces in the first place and divide them into many small interfaces beforehand. This allows much more targeted interfaces to be defined externally.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n 
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Interface Segregation Principle: <\/h3>\n\n\n- Simplifies reuse, testing and maintenance by splitting responsibilities <\/li>\n\n\n\n
- Isolates classes from errors by introducing clear boundaries <\/li>\n\n\n\n
- Enables the replacement of functions without having to understand related classes <\/li>\n\n\n\n
- Reduces cognitive load by isolating topics <\/li>\n\n\n\n
- Focuses attention on a single aspect <\/li>\n<\/ul>\n\n
Dependency Inversion Principle<\/h2>\n\nHigher level classes should not depend on lower level classes<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n 
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
Open Closed Principle<\/h2>\n\nModules should be open for extensions, but closed for modification (changes)<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
Basically, the Open Closed Principle is about taking a strategic approach, because it requires that written code (which has also been tested) should no longer be changed or that the software design should be constructed in such a way that changes can be supported without having to completely rebuild the system.
\nHow can this be achieved? Through inheritance or by providing the module with an interface. This does not change the existing behavior of the module, but merely extends it with additional functions or data.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Open Closed Principle: <\/h3>\n\n\n- Errors are avoided because code that has already been written is left alone <\/li>\n\n\n\n
- Software becomes more maintainable <\/li>\n\n\n\n
- Reuse through the design of stable interfaces <\/li>\n<\/ul>\n\n
Liskov Substitution Principle<\/h2>\n\nIf a derived class is to be implemented, the base class must be extended without changing the behavior of the base function<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
To put it simply: subclasses must behave like base classes. The Liskov Substitution Principle is actually a substitutability principle. This is about interchangeability across class inheritance hierarchies: subclasses must behave like base classes. Look at the graphic with the square and the rectangle: There is a relationship between squares and rectangles: you can say every square is a rectangle, but not every rectangle is a square. As you can see, this inheritance relationship would not work in programming.<\/p>\n
<\/p>\n
So how can you solve this in programming? Instead of the inheritance of square and rectangle, a third class is introduced from which both square and rectangle are derived. This means that the square and rectangle are only linked via the new third class.<\/p>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantage of the Liskov Substitution Principle:<\/h3>\n\n
Security that an implementation can be replaced without changing its behavior<\/p>\n\n
Interface Segregation Principle<\/h2>\n\nEach class should be focused on one aspect or topic only<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The Interface Segregation Principle deals with the separation or decoupling of classes. With the Open Closed Principle, we have learned to work with interfaces. However, interfaces are not without problems either, as they usually tend to get bigger and bigger. As a result, it is becoming increasingly difficult to provide a complete implementation, as more and more code has to be added.<\/p>\n
<\/p>\n
The solution? interfaces in the first place and divide them into many small interfaces beforehand. This allows much more targeted interfaces to be defined externally.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Interface Segregation Principle: <\/h3>\n\n\n- Simplifies reuse, testing and maintenance by splitting responsibilities <\/li>\n\n\n\n
- Isolates classes from errors by introducing clear boundaries <\/li>\n\n\n\n
- Enables the replacement of functions without having to understand related classes <\/li>\n\n\n\n
- Reduces cognitive load by isolating topics <\/li>\n\n\n\n
- Focuses attention on a single aspect <\/li>\n<\/ul>\n\n
Dependency Inversion Principle<\/h2>\n\nHigher level classes should not depend on lower level classes<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
<\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
Basically, the Open Closed Principle is about taking a strategic approach, because it requires that written code (which has also been tested) should no longer be changed or that the software design should be constructed in such a way that changes can be supported without having to completely rebuild the system.
\nHow can this be achieved? Through inheritance or by providing the module with an interface. This does not change the existing behavior of the module, but merely extends it with additional functions or data.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Open Closed Principle: <\/h3>\n\n\n- Errors are avoided because code that has already been written is left alone <\/li>\n\n\n\n
- Software becomes more maintainable <\/li>\n\n\n\n
- Reuse through the design of stable interfaces <\/li>\n<\/ul>\n\n
Liskov Substitution Principle<\/h2>\n\nIf a derived class is to be implemented, the base class must be extended without changing the behavior of the base function<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
To put it simply: subclasses must behave like base classes. The Liskov Substitution Principle is actually a substitutability principle. This is about interchangeability across class inheritance hierarchies: subclasses must behave like base classes. Look at the graphic with the square and the rectangle: There is a relationship between squares and rectangles: you can say every square is a rectangle, but not every rectangle is a square. As you can see, this inheritance relationship would not work in programming.<\/p>\n
<\/p>\n
So how can you solve this in programming? Instead of the inheritance of square and rectangle, a third class is introduced from which both square and rectangle are derived. This means that the square and rectangle are only linked via the new third class.<\/p>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantage of the Liskov Substitution Principle:<\/h3>\n\n
Security that an implementation can be replaced without changing its behavior<\/p>\n\n
Interface Segregation Principle<\/h2>\n\nEach class should be focused on one aspect or topic only<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The Interface Segregation Principle deals with the separation or decoupling of classes. With the Open Closed Principle, we have learned to work with interfaces. However, interfaces are not without problems either, as they usually tend to get bigger and bigger. As a result, it is becoming increasingly difficult to provide a complete implementation, as more and more code has to be added.<\/p>\n
<\/p>\n
The solution? interfaces in the first place and divide them into many small interfaces beforehand. This allows much more targeted interfaces to be defined externally.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Interface Segregation Principle: <\/h3>\n\n\n- Simplifies reuse, testing and maintenance by splitting responsibilities <\/li>\n\n\n\n
- Isolates classes from errors by introducing clear boundaries <\/li>\n\n\n\n
- Enables the replacement of functions without having to understand related classes <\/li>\n\n\n\n
- Reduces cognitive load by isolating topics <\/li>\n\n\n\n
- Focuses attention on a single aspect <\/li>\n<\/ul>\n\n
Dependency Inversion Principle<\/h2>\n\nHigher level classes should not depend on lower level classes<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
<\/p>\n
Basically, the Open Closed Principle is about taking a strategic approach, because it requires that written code (which has also been tested) should no longer be changed or that the software design should be constructed in such a way that changes can be supported without having to completely rebuild the system.
\nHow can this be achieved? Through inheritance or by providing the module with an interface. This does not change the existing behavior of the module, but merely extends it with additional functions or data.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Open Closed Principle: <\/h3>\n\n\n- Errors are avoided because code that has already been written is left alone <\/li>\n\n\n\n
- Software becomes more maintainable <\/li>\n\n\n\n
- Reuse through the design of stable interfaces <\/li>\n<\/ul>\n\n
Liskov Substitution Principle<\/h2>\n\nIf a derived class is to be implemented, the base class must be extended without changing the behavior of the base function<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
To put it simply: subclasses must behave like base classes. The Liskov Substitution Principle is actually a substitutability principle. This is about interchangeability across class inheritance hierarchies: subclasses must behave like base classes. Look at the graphic with the square and the rectangle: There is a relationship between squares and rectangles: you can say every square is a rectangle, but not every rectangle is a square. As you can see, this inheritance relationship would not work in programming.<\/p>\n
<\/p>\n
So how can you solve this in programming? Instead of the inheritance of square and rectangle, a third class is introduced from which both square and rectangle are derived. This means that the square and rectangle are only linked via the new third class.<\/p>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantage of the Liskov Substitution Principle:<\/h3>\n\n
Security that an implementation can be replaced without changing its behavior<\/p>\n\n
Interface Segregation Principle<\/h2>\n\nEach class should be focused on one aspect or topic only<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The Interface Segregation Principle deals with the separation or decoupling of classes. With the Open Closed Principle, we have learned to work with interfaces. However, interfaces are not without problems either, as they usually tend to get bigger and bigger. As a result, it is becoming increasingly difficult to provide a complete implementation, as more and more code has to be added.<\/p>\n
<\/p>\n
The solution? interfaces in the first place and divide them into many small interfaces beforehand. This allows much more targeted interfaces to be defined externally.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Interface Segregation Principle: <\/h3>\n\n\n- Simplifies reuse, testing and maintenance by splitting responsibilities <\/li>\n\n\n\n
- Isolates classes from errors by introducing clear boundaries <\/li>\n\n\n\n
- Enables the replacement of functions without having to understand related classes <\/li>\n\n\n\n
- Reduces cognitive load by isolating topics <\/li>\n\n\n\n
- Focuses attention on a single aspect <\/li>\n<\/ul>\n\n
Dependency Inversion Principle<\/h2>\n\nHigher level classes should not depend on lower level classes<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
Liskov Substitution Principle<\/h2>\n\nIf a derived class is to be implemented, the base class must be extended without changing the behavior of the base function<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
To put it simply: subclasses must behave like base classes. The Liskov Substitution Principle is actually a substitutability principle. This is about interchangeability across class inheritance hierarchies: subclasses must behave like base classes. Look at the graphic with the square and the rectangle: There is a relationship between squares and rectangles: you can say every square is a rectangle, but not every rectangle is a square. As you can see, this inheritance relationship would not work in programming.<\/p>\n
<\/p>\n
So how can you solve this in programming? Instead of the inheritance of square and rectangle, a third class is introduced from which both square and rectangle are derived. This means that the square and rectangle are only linked via the new third class.<\/p>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantage of the Liskov Substitution Principle:<\/h3>\n\n
Security that an implementation can be replaced without changing its behavior<\/p>\n\n
Interface Segregation Principle<\/h2>\n\nEach class should be focused on one aspect or topic only<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The Interface Segregation Principle deals with the separation or decoupling of classes. With the Open Closed Principle, we have learned to work with interfaces. However, interfaces are not without problems either, as they usually tend to get bigger and bigger. As a result, it is becoming increasingly difficult to provide a complete implementation, as more and more code has to be added.<\/p>\n
<\/p>\n
The solution? interfaces in the first place and divide them into many small interfaces beforehand. This allows much more targeted interfaces to be defined externally.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Interface Segregation Principle: <\/h3>\n\n\n- Simplifies reuse, testing and maintenance by splitting responsibilities <\/li>\n\n\n\n
- Isolates classes from errors by introducing clear boundaries <\/li>\n\n\n\n
- Enables the replacement of functions without having to understand related classes <\/li>\n\n\n\n
- Reduces cognitive load by isolating topics <\/li>\n\n\n\n
- Focuses attention on a single aspect <\/li>\n<\/ul>\n\n
Dependency Inversion Principle<\/h2>\n\nHigher level classes should not depend on lower level classes<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
<\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
To put it simply: subclasses must behave like base classes. The Liskov Substitution Principle is actually a substitutability principle. This is about interchangeability across class inheritance hierarchies: subclasses must behave like base classes. Look at the graphic with the square and the rectangle: There is a relationship between squares and rectangles: you can say every square is a rectangle, but not every rectangle is a square. As you can see, this inheritance relationship would not work in programming.<\/p>\n
<\/p>\n
So how can you solve this in programming? Instead of the inheritance of square and rectangle, a third class is introduced from which both square and rectangle are derived. This means that the square and rectangle are only linked via the new third class.<\/p>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantage of the Liskov Substitution Principle:<\/h3>\n\n
Security that an implementation can be replaced without changing its behavior<\/p>\n\n
Interface Segregation Principle<\/h2>\n\nEach class should be focused on one aspect or topic only<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The Interface Segregation Principle deals with the separation or decoupling of classes. With the Open Closed Principle, we have learned to work with interfaces. However, interfaces are not without problems either, as they usually tend to get bigger and bigger. As a result, it is becoming increasingly difficult to provide a complete implementation, as more and more code has to be added.<\/p>\n
<\/p>\n
The solution? interfaces in the first place and divide them into many small interfaces beforehand. This allows much more targeted interfaces to be defined externally.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Interface Segregation Principle: <\/h3>\n\n\n- Simplifies reuse, testing and maintenance by splitting responsibilities <\/li>\n\n\n\n
- Isolates classes from errors by introducing clear boundaries <\/li>\n\n\n\n
- Enables the replacement of functions without having to understand related classes <\/li>\n\n\n\n
- Reduces cognitive load by isolating topics <\/li>\n\n\n\n
- Focuses attention on a single aspect <\/li>\n<\/ul>\n\n
Dependency Inversion Principle<\/h2>\n\nHigher level classes should not depend on lower level classes<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
<\/p>\n
To put it simply: subclasses must behave like base classes. The Liskov Substitution Principle is actually a substitutability principle. This is about interchangeability across class inheritance hierarchies: subclasses must behave like base classes. Look at the graphic with the square and the rectangle: There is a relationship between squares and rectangles: you can say every square is a rectangle, but not every rectangle is a square. As you can see, this inheritance relationship would not work in programming.<\/p>\n
<\/p>\n
So how can you solve this in programming? Instead of the inheritance of square and rectangle, a third class is introduced from which both square and rectangle are derived. This means that the square and rectangle are only linked via the new third class.<\/p>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantage of the Liskov Substitution Principle:<\/h3>\n\n
Security that an implementation can be replaced without changing its behavior<\/p>\n\n
Interface Segregation Principle<\/h2>\n\nEach class should be focused on one aspect or topic only<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The Interface Segregation Principle deals with the separation or decoupling of classes. With the Open Closed Principle, we have learned to work with interfaces. However, interfaces are not without problems either, as they usually tend to get bigger and bigger. As a result, it is becoming increasingly difficult to provide a complete implementation, as more and more code has to be added.<\/p>\n
<\/p>\n
The solution? interfaces in the first place and divide them into many small interfaces beforehand. This allows much more targeted interfaces to be defined externally.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Interface Segregation Principle: <\/h3>\n\n\n- Simplifies reuse, testing and maintenance by splitting responsibilities <\/li>\n\n\n\n
- Isolates classes from errors by introducing clear boundaries <\/li>\n\n\n\n
- Enables the replacement of functions without having to understand related classes <\/li>\n\n\n\n
- Reduces cognitive load by isolating topics <\/li>\n\n\n\n
- Focuses attention on a single aspect <\/li>\n<\/ul>\n\n
Dependency Inversion Principle<\/h2>\n\nHigher level classes should not depend on lower level classes<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
<\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The Interface Segregation Principle deals with the separation or decoupling of classes. With the Open Closed Principle, we have learned to work with interfaces. However, interfaces are not without problems either, as they usually tend to get bigger and bigger. As a result, it is becoming increasingly difficult to provide a complete implementation, as more and more code has to be added.<\/p>\n
<\/p>\n
The solution? interfaces in the first place and divide them into many small interfaces beforehand. This allows much more targeted interfaces to be defined externally.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Interface Segregation Principle: <\/h3>\n\n\n- Simplifies reuse, testing and maintenance by splitting responsibilities <\/li>\n\n\n\n
- Isolates classes from errors by introducing clear boundaries <\/li>\n\n\n\n
- Enables the replacement of functions without having to understand related classes <\/li>\n\n\n\n
- Reduces cognitive load by isolating topics <\/li>\n\n\n\n
- Focuses attention on a single aspect <\/li>\n<\/ul>\n\n
Dependency Inversion Principle<\/h2>\n\nHigher level classes should not depend on lower level classes<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
<\/p>\n
The Interface Segregation Principle deals with the separation or decoupling of classes. With the Open Closed Principle, we have learned to work with interfaces. However, interfaces are not without problems either, as they usually tend to get bigger and bigger. As a result, it is becoming increasingly difficult to provide a complete implementation, as more and more code has to be added.<\/p>\n
<\/p>\n
The solution? interfaces in the first place and divide them into many small interfaces beforehand. This allows much more targeted interfaces to be defined externally.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Interface Segregation Principle: <\/h3>\n\n\n- Simplifies reuse, testing and maintenance by splitting responsibilities <\/li>\n\n\n\n
- Isolates classes from errors by introducing clear boundaries <\/li>\n\n\n\n
- Enables the replacement of functions without having to understand related classes <\/li>\n\n\n\n
- Reduces cognitive load by isolating topics <\/li>\n\n\n\n
- Focuses attention on a single aspect <\/li>\n<\/ul>\n\n
Dependency Inversion Principle<\/h2>\n\nHigher level classes should not depend on lower level classes<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
Dependency Inversion Principle<\/h2>\n\nHigher level classes should not depend on lower level classes<\/h3>\n\n\n \n\n\n \n\n\n \n <\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
<\/h2>\n <\/div>\n\n \n\n \n\n \n <\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n \n\n \n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
<\/p>\n
The idea behind it: Clean up deficiencies. The principles mentioned so far have described classes, created interfaces of classes or extended classes. Now there is one more problem: the classes are still dependent on each other. So what to do? The Dependency Inversion Principle suggests using an interface to decouple two classes from each other. Thus, the first class refers to the interface and the second class implements the interface, so that the second class (because it contains the appropriate interface) can be used as a parameter in the first class.<\/p>\n
<\/p>\n
<\/h4>\n
<\/p>\n <\/div>\n\n \n\n <\/div>\n\n\n
\n <\/div>\n <\/div>\n\n <\/div>\n\n <\/div>\n\n <\/section>\n\n\n<\/p>\n\n
Advantages of the Dependency Inversion Principle: <\/h3>\n\n\n- Enables the reusability of high-level classes by inserting classes <\/li>\n\n\n\n
- As implementations can be exchanged, low-level changes are facilitated <\/li>\n\n\n\n
- Code simplification through standardized work with alternative classes <\/li>\n\n\n\n
- Improves testability<\/li>\n<\/ul>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n
Conclusion? Sounds solid!<\/h2>\n\n
As you can see, the SOLID principles simplify coding and help you to produce clean code. They also play a central role in the day-to-day work of our programmers at mmmake. Stephan Weissenberger, Unit Lead Software Development Lemures:<\/p>\n\n
“The SOLID principles form the foundation of our work. They are easy to learn, but difficult to master. They are one of the first things we teach young developers in order to give them the right introduction to software development. Today, even after several years of experience, we still point out violations of these principles with a grin. The other moans about having been caught making a beginner’s mistake and corrects his work.”<\/p>\n\n
Start your project with our software development!<\/p>\n\n