Back to Basics: Designing Classes (part 1 of 2) - Klaus Iglberger - CppCon 2021
Vložit
- čas přidán 28. 05. 2024
- cppcon.org/
github.com/CppCon/CppCon2021
---
Designing good, maintainable classes is a challenge. Sometimes it even feels like there is a decision to make in every single line of code. This talk will help you master this challenge. It will explain …
* … why small classes are beautiful;
* … why it is so important to encapsulate variation points;
* … why inheritance is rarely the answer for customization;
* … how to write good and maintainable constructors;
* … how to make sure class invariants are maintained;
* … how to handle member data;
* … how to write good member functions;
* … how to write good supporting functions;
* … why your private members are not private at all.
---
Klaus Iglberger
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/).
---
Videos Recorded & Edited by Digital Medium: online.digital-medium.co.uk
*--* - Věda a technologie
one of the worlds greatest speakers on c++. No idea we he hasn't published a book, or even recorded his workshops.
This is just pure gold! I wish I could find more similar quality talks. Not sure if any other good ones, there are so many talks uploaded recently, which overwhelm my digestion.
Great presentation. To the point with clear examples . Klaus doesn't disappoint.
Much appreciated!
He never does :)
One of the best talks I’ve ever seen.
Another great talk from Klaus. Always look forward to his Back to Basics talks
Glad you enjoyed it!
Everyone needs a refresher now and then :) This one held me captivated for the entire duration.
Klaus talks are always very qualitatively dense and great. Back to basics or not, always useful.
Glad you like them!
Excellent talk Klaus. Definitely its one of the best back to basic on design class. Am a big fun of you.
Really enjoying this series.
Klaus Iglberger is an excellent presenter.
Looking forward to more Back to Basics videos.
Glad you like them!
Awesome! Thanks for sharing!
Excellent presentation, congratulations to the presenter and a big thanks to CppCon for sharing..
Thank you too!
Thank you so much for such great presentation 🔥
Thanks for speaking from experience.
Thank you soo much for these valuable lessons! Code examples made it very clear to me.
Glad it was helpful!
Excellent, you explain things very well, practical and to the point.
Glad you think so!
Thank you very much Klaus, excellent talk!
Many thanks!
Nice presentation, easy to follow and understand. Klaus is a great teacher.
Many thanks!
great presentation and easy to understand
Very Informative talk on design decisions !!!
Glad you liked it
Good talk. Enjoyed his training in my uni.
Great to hear!
"#define private public", at least at one point, didn't work with Microsoft compilers because they included the access region in the name mangling.
29:10: I really like the idea of providing the DrawStrategy by means of a template argument to the class. Unfortunately, the slide does not show how one would instantiate such a class. I managed to do this via a functor that I give as the template argument. However, is it also possible via a Lambda or via std::function? Would be very grateful if someone could explain how to do that.
Really good talk
Designing classes is a constant search for orthogonalities.
Exple:
Circle->(implements)->the shape interface.
Circle::draw -> calls RenderEngine::draw.
Circle::draw generates the vertices of a circle, RenderEngine::draw uses whatever drawing engine (opengl, vulkan, Dx..etc) to lay these vertices on a color buffer.
Instantiating a Circle by giving it a derived class of "DrawXXXXstrategy" means the user have to know which concrete class he has to use to render his circle. However this information is only relevant to the render engine, it is the one and only object which should know about the underlying platform.
As an implementer of circle::draw method, i have only to say:
void circle::draw(radius, resolution)
{
vector circumference;
for(int i=0; i
great advice. any books / resources you recommend?
Thanks for a really useful talk!
Glad it was helpful!
Very nice presentation!
Thank you very much!
Great presentation.
Thanks for watching
About testing private members (of a class type). I would phrase it slightly different. Do NOT test them as part of the owning class. If it is a private member of a specific other class type then test the member class in isolation first. Also allow for the member to be injectable (inject interface or as template parameter) so you can test the using class using a "mocked instance" as member.
Great lecture!
Thank you!
Doesn't the std::function version of the Strategy pattern leave it open to any and all callable with the function signature?... No type checking at all?....
I would prefer Length to Size for the second array template parameter. Size is too easily confused with the size in memory, and in some ways (e.g., sizeof) could be more confusing than just N.
You can apply the law of least suprise here too; the stl containers use size, so use that one as well.
What operating system does Klaus use?
Thank you so much for this talk! I need to get a copy of the gang of four book and test out the new features in the standard. I think that learning this is super valuable.
Glad it was helpful!
13:29 Can anyone tell me what font is that (for the class definition) ? Its gorgeous!
It's PT Mono.
41:13 #define class struct is of course the best option here, as showed in the first answer😂
At 43:34 he says that by making the test class a friend you couple it into the production code. Can someone elaborate?
You mean 42:35? My understanding is that if you make the test class as a friend, then this line of declaration will pollute your actual code of specific functions. Imagine that the production environment code does not have any test class, then the line of code will become dead and will never be used.
I didn't understand a few things. It would be nice to have more examples. For example, how 'destroy' function should be moved away to make it testable. Also when explaining "Template Method" 's purpose, you said that it solves certain type of problem, but I didn't understand where the problem is in that case.
Slide 79: You cannot implement copy ctor or assignment for that class. A type that has a move-only member like std::unique_ptr is automatically move-only as well. There is no Rule of 5 in this case.
Isn't it only the compiler-generated copy constructor is inhibited? I tried to create the same Widget class in MSVC and there was no problem to create a user-defined copy constructor. You just need to do something different than move for the unique_pointer member, perhaps initialise it with a factory/clone method?
That feel when having used #define private public a bunch of time in unit tests 😅. It is a hack indeed, and it is probably truly ghastly, but I don't think he really justifies that. Why is it actually so bad?
Why are the Germans such good C++ teachers?
Maybe because there are a lot of users of C++ in Germany and people had to get good in it because they were using it so much. I mean considering that Germany produces a lot of mechanization and industrial equipment..
Your rapper name is Santa Klaus
Less data at the expense of more code is the only way. In real time you have to throw away good design in favour of less calls and the only way you can do that is make more functions, more code, that only need to be called once. The call itself carries values inherently and virtualisation provides that far better than delegation. When you connect to a real-time server you have to throw relationships out of the window. They are too inefficient. This back and forth as you traverse the data relationships is all wrong. Send one query. Get back a block that contains enough data that will stop you from having to retrieve relationships by sending more queries. Polymorphism carries implied intent. Delegation does not.
This performance is dramatic that it gives me cringe overflow with undefined behaviour
not fun indeed
apply those principles descibed on the video is the best way to achieve slow code and the slow code for me is pure evil