Law of Demeter: A Practical Guide to Loose Coupling - Kris Jusiak - CppCon 2021
Vložit
- čas přidán 11. 01. 2022
- cppcon.org/
github.com/CppCon/CppCon2021
---
In this practical session, we will go through examples that follow and/or violate the Law of Demeter principle (LoD) [1].
We will take a deep dive into what kind of design issues that exposes and how to fix them.
Additionally, we will focus on the testing aspect of following the LoD principle together with Single Responsibility and Dependency Inversion principles.
At the end of this session, the audience will have a better understanding of how to write a loosely coupled code, how to easily test it and why the Law of Demeter principle is so important in Software Design.
Let's !"only talk to our immediate friends" at CppCon-2021!
---
Kris Jusiak
Kris is a Software Architect passionate about programming and who has worked in different industries over the years including telecommunications, games and most recently finance for Quantlab Financial, LLC. He has an interest in modern C++ development with a focus on performance and quality. He is an open-source enthusiast with multiple open-source libraries where he uses template meta-programming techniques to support the C++ rule - "Don't pay for what you don't use" whilst trying to be as declarative as possible with a help of domain-specific languages. Kris is also a keen advocate of extreme programming techniques, Test/Behavior Driven Development and truly believes that 'the only way to go fast is to go well!'.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
CZcams Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
*--* - Věda a technologie
In a lot of early examples, the speaker describes the code as "tightly coupled", but doesn't seem to say what it's tightly coupled to.
Excellent talk!
Maybe I am mad, but creating 1000 interfaces for every single class that has a simply different use of some part of the system is neither clear, nor fast (devirtualization won't help you, most of the time), nor easy to navigate the code (ok, where is the *default* and *only* implementation of the interface, so that I can jump through this indirect call)?
TLDR
1. Use DI to loose coupling
2. Use it through constructors to avoid being coupled to DI framework
3. Prefer template+concepts to easily change implementation without any additional runtime cost.
Personal opinion - 3 requires extra care to avoid increase in compilation times.
Runtime cost is overrated in c++ programming in my opinion.. With all the power of metaprogramming in last year a developer says "Oh my God a virtual function!!! It's sooooo baaaaad!" and the function reads a file, for example... a good design should check WHERE it can be useful and where not. In last years we're abusing of metaprogramming and we're saying that virtual functions, polymorphism and so on are bad only because we can do it better with metaprogramming, while in reality 99% of time is only a waste of time and effort make a design choice with metaprogramming while normal and old polymorphism, pointer indirection and so on can make the same work with much less effort and NO runtime performance degradation, because they not involve a critical path.
templates solely for decoupling pushes code into headers and slows compilation..
Using concepts + type erasure to impose interfaces for dependency injection sounds promising, however C++20 is still 5-10 years away from being usable by many projects. Afaict 2-layer inheritance with an abstract base class is the most straightforward alternative.
read sfinae. And the std lib can just be implemented in your custom library. A bigger problem I have with type erasure is the (potential) dynamic allocation by std function and std any.
I'd say "being usable by many projects" should be written as "being usable by many developers".
@@wjrasmussen666 Language version is generally a per-project decision so I think the original is correct.
How can I write the template class named that is used like this:
using first_name = named;
The "using" part is visible in the slides here: czcams.com/video/QZkVpZlbM4U/video.html
One obvious solution was missing from the talk... Use build system (e.g. CMake) and depending on the platform (Linux, Windows, Mac) and need (production, unit testing) include different implementation of the class with the same name (and perhaps even same declaration).
In a fair amount of cases there is no need for more than one implementation inside the same binary so why bother the API with it? (a nice side effect is that you don't need to rely on ifdefs for platform specific code while also keep virtual functions, inheritance and templates out of the places where they aren't needed for other stuff)
when writting your mocked implementation (for unit tests) then you depend on a header file that declares various members + private functions using types you don't care about for your mocked implementation, but still you depend on them, while not being able to add new members that would help you to mock your instance
unless you use the Pimpl, but in such case you just recreated the principle of a virtual
Well, "Law of Demeter" was click-bait - it was briefly mentioned and that was it. The talk is all about SOLID and other acronyms.
"Don't chain method calls" is not always applicable. Look at how std::ranges works by design. Or think about chaining monads (and_then, or_else). If the uniform call syntax ever becomes accepted, we'll get more chaining and that isn't a bad thing. It can improve readability when used well. E.g LINQ in C# is a good example imho
I think that issue that troubles people about chaining mainly refers to “getter” functions, in which chains explicitly depend on the exact structure of objects/components in a design, and prevents changing the design (for example adding layers of indirection). Sean Parent might call it “incidental data structure”
He mentions this exception explicitly just after stating the rule. The rule is just a proxy for "only talk to your immediate friends", where each method call represents another step along the dependency chain. Ranges and monad method chains do not represent dependencies.
Easy to change (as he references: ETC) should NOT be your no.1 concern, (it could possibly be?), depended on your application, but in MOST cases, it probably isn’t even in the top 10 or even top 20 goals or design priorities.
Interesting perspective. I'm guessing you just don't roll out new features or fix bugs then since those are changes?
But SOLID is always very object oriented. The example of the cppcon_talk makes a speaker object and attendees objects. But isn't a presentation all about message passing->functional? Haha. Just trying to say that SOLID is quite "retro". OO is no longer the one ring to rule them all. Still a nice presentation by the way. I dislike the speaker concept, as it isn't sufficiently generic. It doesn't add value to the whole. You don't want concepts for everything
I think SOLID repels OO -- it did for me. For example, almost all OO software fights single responsibility, makes open/closed more difficult (mixins are templates in C++), brings in the capability to violate Liskov's at all, breaks interface segregation practically immediately, and causes a lot of pain to invert dependencies. I don't think SOLID itself is retro.
Strange. Singletones have their use cases. One may not just say sigletone is not ok without any particular sane context.
Same goes for all the rest.
Singletons make your code really hard to test. Probably the video below will address your concerns in more comprehensive way
czcams.com/video/K5c7uvWe_hw/video.html
Pay attention to the topic. The topic is dependency and coupling. The context is that singletons produce coupling. Code that has been written in the orbit of a singleton cannot exist without it, it becomes tightly coupled, and more coupling than strictly necessary is unhealthy, because you get a system that is more difficult to test than necessary, it becomes more difficult to refactor and rework, that's the premise.
And singletons are a particularly good/bad example, because they are quite unnecessary. Something that exists one of, might fundamentally as well exist zero or several of.
The name of the talk is "Guide to Loose Coupling". The "sane context" you're looking for was there all along, it's assumed that you are trying to avoid writing tightly coupled code. "Tight coupling has use cases! Rawr!" is a pretty funny comment to make under this video.
I think if you had a very small program that you can test without unit tests, from the outside, singletons might be okay. If you're in your bedroom, sure, go ahead and take off your pants. But if there's a big crowd of people, or even just a small gathering at home, you're probably going to want to leave your pants on. No singletons. You should be embarrassed to bring out your singleton.