Breaking Dependencies: The SOLID Principles - Klaus Iglberger - CppCon 2020
Vložit
- čas přidán 15. 05. 2024
- cppcon.org/
github.com/CppCon/CppCon2020/...
---
SOLID is an abbreviation for five of the most important software design principles:
- (S)ingle Responsibility Principle
- (O)pen-Closed Principle
- (L)iskov Substitution Principle
- (I)nterface Segregation Principle
- (D)ependency Inversion Principle
For almost two decades, these principles have proven to be a valuable set of guidelines to cope with software dependencies. Although initially introduced as guidelines for object-oriented programming, they have become a universal set of guidelines that can be used equally well for procedural, functional or generic programming. In this talk I'll recap the SOLID principles and explain why they form such a valuable set of universal design guidelines. Also, I'll go into detail about several common misconceptions.
---
Klaus Iglberger is a freelancing C++ trainer and consultant. He has finished his PhD in computer science in 2010 and since then is focused on large-scale C++ software design. He shares his experience in popular advanced C++ courses around the world (mainly in Germany, but also the EU and US). Additionally, he is the initiator and lead designer of the Blaze C++ math library (bitbucket.org/blaze-lib/blaze...) and one of the organizers of the Munich C++ user group (www.meetup.com/MUCplusplus/).
---
Streamed & Edited by Digital Medium Ltd - events.digital-medium.co.uk
events@digital-medium.co.uk
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----* - Věda a technologie
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
Probably the best explanation of the SOLID principles. Thanks Uncle Klaus! Always find yr talks very informative.
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
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.
One of the things which i really like about his talk is short and concise . But he also pointed to the right spot.
Klaus lglberger your talks are great. I love to watch your videos. Thank you cppcon.
Glad you like them!
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.
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?
This is of the best explanations of SOLID principles. 🙏
Great to hear!
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.
Thank you for the presentations and also for uploading.
Glad you like them!
Thank you, very useful talk indeed!
Loved the clear explanations with examples!
Glad it was helpful!
A solid presentation :)
Very kind explanation. Thank you !!!
Excellent talk. Thanks a lot Klaus
Glad you liked it!
Guidelines
17:00 SRP · 30:27 OCP · 41:15 LSP - 3 guidelines here · 48:10 ISP · 57:33 DIP
Thank u so much for the clear explanation.
This is helping me a lot. Thank you so much :)
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.
Great Talk !!
Great explanation of SOLID.
Thanks!
Sounds like the single responsibility principle applies the UNIX philosophy to coding practices. Very nice.
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.
I have become a fan of you Klaus iglberger
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 :)
Link to mentioned video: Dynamic Polymorphism with Metaclasses and Code Injection
czcams.com/video/A4MH8KWna1g/video.html
Awesome talk!!
Thank you!
thanks, Klaus.
Thank you too!
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.
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.
If I suddenly decide to use strategy design pattern, is it violate to open-close principle? changing the constructor?
How to understand "Contravariance of method arguments in a subtype" at 32:46
What about a templated DrawStrategy interface? 😉
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
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.
You are way better at explaining this than Uncle Bob.
In 51:32 the in the drawCircle is an abbreviation for what?
Interface, I think.
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.
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.
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.
Very nice library :)
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.
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.
Could you please provide accurate subtitles for this video?
If your OO design feels unclean, you have too few classes and not too many. (Old OO saying)
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.
18:10
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.
Wikipedia is generally a good resource, but using it repeatedly as reference is really not a good thing.
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.
This talk is a masterpiece. CppCon, you must take our money selling us a SOLID T-Shirt.