really good talk didactically, I love how klaus shows "wrong" approaches to interpreting the principles. Really makes how to apply these general rules a bit less abstract
Thanks Klaus, there is a few days of material in this 1 hr video. It was nice to see you not just present the canonical examples, but to expand and explain them.
Awesome talk, thank you! I hope to see more of these architecture/design focused talks. Does anyone have other good lectures like this one that I should watch?
The problem with the square/rectangle examples is that in "math" things are immutable. For *read only* operations, square is a special case of rectangle and a square can be used by any code that expects a rectangle. Adding constraints to the values returned from the accessors does not affect the caller. But "special case" affects modification in the wrong way to support IS-A relationships. It adds constraints to the arguments of the functions. For the opposite of an immutable class; say, a system for creating objects based on serialized data streams, the IS-A relationship would be the other way around. My proposal: There is no square class. Merely a square creation function that returns a rectangle. Thinking about the needs of an actual program -- e.g. something for drawing and analyzing UML diagrams -- the code doesn't benefit from having a square. Generally it's written to look at the width for some things and look at the height for some things, and having them be equal is not really important anywhere.
But a square is also a special case of a regular polygon, what if you have some other function that makes sense for those but not for a rectangle? Or if there are other objects like rhombuses or trapezoids? It seems to me that the correct thing to do for the shapes is just to avoid changing existing objects, and just create new ones instead.
@@Reddles37 hmm you are right. come to think of it, setwidth shouldn't be a method of rectangle at atll, it should be a seperate class that does scaling that takes in a square, scales it and returns a rectangle.
Just make rectangle/square a struct and have non-member functions operate on it. You can even use function overloading to achieve something polymorphic-like without requiring unnecessary encapsulation.
The SOLID Principles Guidelines Single-Responsibility Principle (SRP) - Prefer cohesive software entities. Everything that does not strictly belong together, should be separated. Open-Closed Principle (OCP) - Prefer software design that allows the addition of types or operations without the need to modify existing code. Liskov Substitution Principle (LSP) - Make sure that inheritance is about behavior, not about data. - Make sure that the contract of base types is adhered to. - Make sure to adhere to the required concept. Interface Segregation Principle (ISP) - Make sure interfaces do not induce unnecessary dependencies. Dependency Inversion Principle (DIP) - Prefer to depend on abstractions (i.e. abstract classes or concepts) instead of concrete types.
The argument at 25:00 concerning the free functions is somewhat debatable. With function overloading, if we forget to define the function for a given struct, then a linker error appears. The need for a natural order in the std::vector is not clear, why not a std::vector, std::vector, etc? If we need to draw in a specific order, just define it. Boost can help.
26:10: that would be a perfect use case for template functions, no? Because I could call the free function draw and use have it distinguish between different implementations.
I am a little confused with your definition of low level and high level in the DIP example on page 89. If View depends on Model, I would call View the high-level module and Model the low-level module. Is that not the usual definition of high and low level? The same confusion occurs on slide 92 when you say that the STL is high-level. I would consider it the lowest level library in the codebase. Besides that I enjoyed your talk very much :)
I find the problem of self-contained draw functions vs external draw classes very interesting. In my own 3D visualization program, I have separate renderer classes that renders subsets of objects in my scene. But when I look at some game engines and graphics engines, it seems like every single object renders individually? So you can get a very high amount of draw calls if there are alot of objects in the scene.
Deriving Rectangle from Square violates the Liskov Substitution Principle even for immutable objects. For example consider the following function bool isSquare(Square& s) { assert(s.getWidth() == s.getHeight()); return true; } This function works with all squares but not will some rectangles. Thus a rectangle cannot be substituted into code that expects a square. However, deriving Square from Rectangle works for immutable objects.
With the example for the Interface Segregation Principle my first inclination would be to, if possible, abstract the different graphic APIs like OpenGL, Vulcan, etc rather than use Strategy. I guess it's similar except that an abstraction layer doesn't have to know about all the different shapes whereas the Strategy classes do.
The problem with doing that, potentially, is that you would have to make the interface generic enough to handle all APIs you plan on supporting, or you would have to emulate API-specific features. In either case, you're probably better off using policy-based template metaprogramming, especially for high-performance code. With metaprogramming, you don't have to worry as much about the runtime cost of your abstraction, and you can specialize and easily add new API policies.
I disagree with the LSP part. Why not in example B, make the rectangle height and width set functions protected and then allow constructors to control what is set because of a square Is-A rectangle in geometry. A rectangle is in some cases a square which is correct. The difference is the constructor only. Having the setter public means that instances of squares can mutate. Is that a requirement?
Another approach which you can use, is to make square privately inheriting from rectangle. This way the setHeight() and setWidth() methods cannot be accessed by users of the square class: class Square : private Rectangle { public: Square(double a) : Rectangle {a, a} {} … }; But this is a C++ specific solution.
I wish people stopped using shapes and drawing as examples, because no one at all concerned with performance would ever dream of making shapes anything but PODs. I find that language AST is a better example where you have a complicated recursive data structure that you operate on using visitors. The whole drawing shapes thing is a remnant of the times where retained point-and-click UI was the hot new thing and people were competing to out-overengineer each other in that domain.
People use shapes, animals, vehicles etc. to describe systems that are typically described by inheritance because most audiences already understand what those things are, and how they relate to each other. While an AST might be a better example for some, it would be an awful example for anyone that doesn't already have a basic understanding of ASTs. It's all about minimising the cognitive load for the audience.
35:00 A friend of mine commented the following for Option B. If you have a function that takes a Square& then it wouldn't make sense if you didn't actually get a square, but rather some non-square rectangle.
the problem you are seeing here is called the expression problem. you want to easily add both new types and new functions. this cannot be solved by either OO or functional, you need eg multiple dispatch.
In the Liskov substitution principle example, would it be acceptabe to have a base Square class with a setSize method which takes 1 argument, and a Rectangle class, in which the setSize method would set both dimensions, but which would also have setWidth and setHeight method? This way, a rectangle used in place of a square would work just fine, but when treated as a rectangle would add new behavior.
The essential issue with the design is that a rectangle is a square but not vice versa, so even if you can somehow workaround this restriction there will always be some aspects that you cannot represent in square for rectangle (e.g. diagonal, etc.)
I think that would properly fulfill LSP, but any variation of option A defeats the purpose of inheriting in the first place. Square can reuse the drawing and area calculation code from rectangle, but rectangle gains nothing useful by inheriting from square, and is illogical to boot. Since it's only the mutation functions that have conflicting logic, one option would be to make an intermediate rectangle class that has everything except the mutation functions, and then the actual rectangle and square classes independently inherit that.
I don't really understand why we keep going back to the SOLID principles. This talk obviously targets a beginner audience but still... I believe it can be formulated in much better terms without ever needing to mention the SOLID principles. For example, Klaus' talk "Free your functions" was much better in that aspect. Otherwise we keep spending time just to try disambiguating the whole thing. Which is not very interesting in my opinion. The SOLID principles is also widely criticized and this talk does not reflect that.
"SOLID principles is also widely criticized" -> true. However, all the people I have seen do that tend be really bad with extensible architecture. That said, they also tend to write very performant code for a specific task like the enum solution in the trade off table in the video. I learned to live it. If I know that there is a future case in pipeline that needs extension I warn during review else there is nothing much objectively from stopping a person to ignore extensibility.
These principles are all BS! You either do software that works and useful for people or not! Do not expect to be a good software engineer by memorizing such things. The only way to be proficient in software is to spend so much time in programming and tring out things.
Probably the best explanation of the SOLID principles. Thanks Uncle Klaus! Always find yr talks very informative.
Principle Timestamps:
Single Responsibility Principle - 4:45
Open/Closed Principle - 17:45
Liskov Substitution Principle - 30:55
Interface Segregation Principle - 42:00
Dependency Inversion Principle - 48:45
Iglberger is becoming another one of my favorite C++ presenters besides Herb Sutter and Scott Meyers.
Oh, does he also only write books and no code? Would explain why he chooses a 90s UI toolkit as an example.
@@bernadettetreual he is the author of blaze math library
He is my favorite at the moment (except Bjarne Stroustrup of course)
really good talk didactically, I love how klaus shows "wrong" approaches to interpreting the principles. Really makes how to apply these general rules a bit less abstract
One of the things which i really like about his talk is short and concise . But he also pointed to the right spot.
Klaus is great. I attended his C++ courses in Munich and this really improved the way I program. Don't be a cowboy programmer. Be a SOLID programmer.
Klaus lglberger your talks are great. I love to watch your videos. Thank you cppcon.
Glad you like them!
This is of the best explanations of SOLID principles. 🙏
Great to hear!
Thanks Klaus, there is a few days of material in this 1 hr video. It was nice to see you not just present the canonical examples, but to expand and explain them.
Awesome talk, thank you! I hope to see more of these architecture/design focused talks. Does anyone have other good lectures like this one that I should watch?
The problem with the square/rectangle examples is that in "math" things are immutable. For *read only* operations, square is a special case of rectangle and a square can be used by any code that expects a rectangle. Adding constraints to the values returned from the accessors does not affect the caller.
But "special case" affects modification in the wrong way to support IS-A relationships. It adds constraints to the arguments of the functions.
For the opposite of an immutable class; say, a system for creating objects based on serialized data streams, the IS-A relationship would be the other way around.
My proposal: There is no square class. Merely a square creation function that returns a rectangle. Thinking about the needs of an actual program -- e.g. something for drawing and analyzing UML diagrams -- the code doesn't benefit from having a square. Generally it's written to look at the width for some things and look at the height for some things, and having them be equal is not really important anywhere.
But a square is also a special case of a regular polygon, what if you have some other function that makes sense for those but not for a rectangle? Or if there are other objects like rhombuses or trapezoids? It seems to me that the correct thing to do for the shapes is just to avoid changing existing objects, and just create new ones instead.
@@Reddles37 hmm you are right. come to think of it, setwidth shouldn't be a method of rectangle at atll, it should be a seperate class that does scaling that takes in a square, scales it and returns a rectangle.
Just make rectangle/square a struct and have non-member functions operate on it. You can even use function overloading to achieve something polymorphic-like without requiring unnecessary encapsulation.
The SOLID Principles Guidelines
Single-Responsibility Principle (SRP)
- Prefer cohesive software entities. Everything that does not strictly belong together, should be separated.
Open-Closed Principle (OCP)
- Prefer software design that allows the addition of types or operations without the need to modify existing code.
Liskov Substitution Principle (LSP)
- Make sure that inheritance is about behavior, not about data.
- Make sure that the contract of base types is adhered to.
- Make sure to adhere to the required concept.
Interface Segregation Principle (ISP)
- Make sure interfaces do not induce unnecessary dependencies.
Dependency Inversion Principle (DIP)
- Prefer to depend on abstractions (i.e. abstract classes or concepts) instead of concrete types.
Loved the clear explanations with examples!
Glad it was helpful!
Very kind explanation. Thank you !!!
Sounds like the single responsibility principle applies the UNIX philosophy to coding practices. Very nice.
Guidelines
17:00 SRP · 30:27 OCP · 41:15 LSP - 3 guidelines here · 48:10 ISP · 57:33 DIP
I have become a fan of you Klaus iglberger
You are way better at explaining this than Uncle Bob.
Thank you for the presentations and also for uploading.
Glad you like them!
Great explanation of SOLID.
Thanks!
Excellent talk. Thanks a lot Klaus
Glad you liked it!
The argument at 25:00 concerning the free functions is somewhat debatable. With function overloading, if we forget to define the function for a given struct, then a linker error appears. The need for a natural order in the std::vector is not clear, why not a std::vector, std::vector, etc? If we need to draw in a specific order, just define it. Boost can help.
Link to mentioned video: Dynamic Polymorphism with Metaclasses and Code Injection
ua-cam.com/video/A4MH8KWna1g/v-deo.html
A solid presentation :)
26:10: that would be a perfect use case for template functions, no? Because I could call the free function draw and use have it distinguish between different implementations.
Thank u so much for the clear explanation.
This is helping me a lot. Thank you so much :)
I am a little confused with your definition of low level and high level in the DIP example on page 89. If View depends on Model, I would call View the high-level module and Model the low-level module. Is that not the usual definition of high and low level? The same confusion occurs on slide 92 when you say that the STL is high-level. I would consider it the lowest level library in the codebase. Besides that I enjoyed your talk very much :)
This talk is a masterpiece. CppCon, you must take our money selling us a SOLID T-Shirt.
Awesome talk!!
Thank you!
thanks, Klaus.
Thank you too!
Thank you, very useful talk indeed!
I find the problem of self-contained draw functions vs external draw classes very interesting. In my own 3D visualization program, I have separate renderer classes that renders subsets of objects in my scene. But when I look at some game engines and graphics engines, it seems like every single object renders individually? So you can get a very high amount of draw calls if there are alot of objects in the scene.
Deriving Rectangle from Square violates the Liskov Substitution Principle even for immutable objects. For example consider the following function
bool isSquare(Square& s) {
assert(s.getWidth() == s.getHeight());
return true;
}
This function works with all squares but not will some rectangles. Thus a rectangle cannot be substituted into code that expects a square.
However, deriving Square from Rectangle works for immutable objects.
How to understand "Contravariance of method arguments in a subtype" at 32:46
With the example for the Interface Segregation Principle my first inclination would be to, if possible, abstract the different graphic APIs like OpenGL, Vulcan, etc rather than use Strategy. I guess it's similar except that an abstraction layer doesn't have to know about all the different shapes whereas the Strategy classes do.
The problem with doing that, potentially, is that you would have to make the interface generic enough to handle all APIs you plan on supporting, or you would have to emulate API-specific features. In either case, you're probably better off using policy-based template metaprogramming, especially for high-performance code. With metaprogramming, you don't have to worry as much about the runtime cost of your abstraction, and you can specialize and easily add new API policies.
I disagree with the LSP part. Why not in example B, make the rectangle height and width set functions protected and then allow constructors to control what is set because of a square Is-A rectangle in geometry. A rectangle is in some cases a square which is correct. The difference is the constructor only. Having the setter public means that instances of squares can mutate. Is that a requirement?
Another approach which you can use, is to make square privately inheriting from rectangle. This way the setHeight() and setWidth() methods cannot be accessed by users of the square class:
class Square : private Rectangle {
public:
Square(double a) : Rectangle {a, a} {}
…
};
But this is a C++ specific solution.
Great Talk !!
If I suddenly decide to use strategy design pattern, is it violate to open-close principle? changing the constructor?
what would the code look like at 53:45 for the DrawCircle interface?
Mostly 1 pure virtual function -> virtual void draw(const circle& c) = 0
Very nice library :)
I wish people stopped using shapes and drawing as examples, because no one at all concerned with performance would ever dream of making shapes anything but PODs. I find that language AST is a better example where you have a complicated recursive data structure that you operate on using visitors. The whole drawing shapes thing is a remnant of the times where retained point-and-click UI was the hot new thing and people were competing to out-overengineer each other in that domain.
People use shapes, animals, vehicles etc. to describe systems that are typically described by inheritance because most audiences already understand what those things are, and how they relate to each other.
While an AST might be a better example for some, it would be an awful example for anyone that doesn't already have a basic understanding of ASTs. It's all about minimising the cognitive load for the audience.
I don't know what is AST.
35:00
A friend of mine commented the following for Option B.
If you have a function that takes a Square& then it wouldn't make sense if you didn't actually get a square, but rather some non-square rectangle.
What about a templated DrawStrategy interface? 😉
the problem you are seeing here is called the expression problem. you want to easily add both new types and new functions. this cannot be solved by either OO or functional, you need eg multiple dispatch.
In 51:32 the in the drawCircle is an abbreviation for what?
Interface, I think.
In the Liskov substitution principle example, would it be acceptabe to have a base Square class with a setSize method which takes 1 argument, and a Rectangle class, in which the setSize method would set both dimensions, but which would also have setWidth and setHeight method? This way, a rectangle used in place of a square would work just fine, but when treated as a rectangle would add new behavior.
The essential issue with the design is that a rectangle is a square but not vice versa, so even if you can somehow workaround this restriction there will always be some aspects that you cannot represent in square for rectangle (e.g. diagonal, etc.)
I think that would properly fulfill LSP, but any variation of option A defeats the purpose of inheriting in the first place. Square can reuse the drawing and area calculation code from rectangle, but rectangle gains nothing useful by inheriting from square, and is illogical to boot.
Since it's only the mutation functions that have conflicting logic, one option would be to make an intermediate rectangle class that has everything except the mutation functions, and then the actual rectangle and square classes independently inherit that.
If your OO design feels unclean, you have too few classes and not too many. (Old OO saying)
Could you please provide accurate subtitles for this video?
I don't really understand why we keep going back to the SOLID principles.
This talk obviously targets a beginner audience but still...
I believe it can be formulated in much better terms without ever needing to mention the SOLID principles.
For example, Klaus' talk "Free your functions" was much better in that aspect.
Otherwise we keep spending time just to try disambiguating the whole thing.
Which is not very interesting in my opinion.
The SOLID principles is also widely criticized and this talk does not reflect that.
"SOLID principles is also widely criticized" -> true. However, all the people I have seen do that tend be really bad with extensible architecture. That said, they also tend to write very performant code for a specific task like the enum solution in the trade off table in the video. I learned to live it. If I know that there is a future case in pipeline that needs extension I warn during review else there is nothing much objectively from stopping a person to ignore extensibility.
These principles are all BS! You either do software that works and useful for people or not! Do not expect to be a good software engineer by memorizing such things. The only way to be proficient in software is to spend so much time in programming and tring out things.
You should offer some meritable criticism of SOLID instead of baselessly dismissing it.
God help the people who have to maintain your code.
18:10
Wikipedia is generally a good resource, but using it repeatedly as reference is really not a good thing.