Remove Messy Constructor Calls | Clean Code
VloĆŸit
- Äas pĆidĂĄn 15. 08. 2023
- Download the source code from Patreon: / source-code-for-87754379
One of the common stumbling blocks developers encounter in writing code is the problem of nesting constructor calls within object composition. At first glance, this approach can seem efficient in that it allows for the Single Responsibility Principle and the development of many small, focused - perfect, why not say? - classes.
However, this can quickly lead to intricate and harder-to-decipher code through a very peculiar practice - nesting constructor calls. As the functionalities we implement grow, they often make nested constructor calls inevitable, as small objects in a complex domain model become deeply intertwined. This approach often results in a code structure that's densely packed with technicalities, obscuring the actual intent, and making it hard to decipher the code's primary purpose at a quick glance.
The heart of the challenge is the overshadowing of the 'what' by the 'how'. Technical details pouring out of complex constructor nesting structures can unintentionally mask the primary intention of the code.
We need a paradigm shift towards intention-revealing code. By leveraging design techniques such as extension methods, developers can encapsulate the complex constructor chains, giving them a meaningful and semantically-rich name that clearly reflects the purpose of the code segment, sidestepping its inner technical workings.
From this video, you will learn how to transform the code into a self-documenting entity. With clear, purpose-driven naming, a developer would swiftly grasp a segment's intent without getting bogged down by its construction intricacies. In the end, while the technical depth of code remains paramount, you will learn how to balance it with clarity and a semantic-driven narrative, enhancing efficiency and overall intuitiveness in the development process.
Thank you so much for watching! Please like, comment & share this video as it helps me a ton!! Don't forget to subscribe to my channel for more amazing videos and make sure to hit the bell icon to never miss any updates.đ„â€ïž
â đ Become a patron âș / zoranhorvat
â đ Subscribe âș / @zoran-horvat
â Learn more from video courses:
Beginning Object-oriented Programming with C# âș codinghelmet.com/go/beginning...
â Collections and Generics in C# âș codinghelmet.com/go/collectio...
â Making Your C# Code More Object-oriented âș codinghelmet.com/go/making-yo...
âŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹ
â CONNECT WITH ME đ±đš
đBecome a patron âș / zoranhorvat
đBuy me a Coffee âș ko-fi.com/zoranhorvat
đł Pluralsight Courses âș codinghelmet.com/go/pluralsight
đž Udemy Courses âș codinghelmet.com/go/udemy
đž Join me on Twitter âș / zoranh75
đ Read my Articles âș codinghelmet.com/articles
đž Join me on LinkedIn âș / zoran-horvat
âŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹ
đš About Me đš
Hi, Iâm Zoran, I have more than 20 years of experience as a software developer, architect, team lead, and more. I have been programming in C# since its inception in the early 2000s. Since 2017 I have started publishing professional video courses at Pluralsight and Udemy and by this point, there are over 100 hours of the highest-quality videos you can watch on those platforms. On my CZcams channel, you can find shorter video forms focused on clarifying practical issues in coding, design, and architecture of .NET applications.â€ïž
âŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹâŹ
âĄïžRIGHT NOTICE:
The Copyright Laws of the United States recognize a âfair useâ of copyrighted content. Section 107 of the U.S. Copyright Act states: âNotwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phono records or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright." This video and our youtube channel, in general, may contain certain copyrighted works that were not specifically authorized to be used by the copyright holder(s), but which we believe in good faith are protected by federal law and the Fair use doctrine for one or more of the reasons noted above.
âFor copyright or any inquiries, please contact us at zh@codinghelmet.com
#csharp #dotnet #objectorientedprogramming - VÄda a technologie
Since I have followed you, I have been applying that technique of exposing "What" and not "How". I must admit you have played essential role in improving my coding style, now I am proud of my code which is there in Production.
I am glad to hear that. Indeed, telling what will happen but encapsulating how - that is the critical enabler to writing flexible, adaptable code which is, in turn, the critical requirement in enterprise-grade applications.
IoC + interfaces + functional programming + c# 10/11 with no null + immutable objects with pure functions + SOLID == give me the strongest code without any bug except probably the logical ones. Functional programming with using LINQ provides much more readable code without loops if-else branches and as a result no bugs. Thanks to Zoran Horvat. I listened all your Pluralsight lectures. It is terrific.
Knowing a programming concept and how to effectively apply it is what draws out the learning process. Sometimes I feel like I've been using nails to hang pictures until you come along and demonstrate how to use them to build a house. Your practical and real-world examples make all the difference. Great video!
Thanks!
âI donât like to think when Iâm writing code.â
That should be on a tee shirt.
Agree.
Excellent, I've used this style of programming years ago while I was using c# at my day job but have since forgotten as I'm using Python daily.
Thank you for the video, much appreciated. Always good to see techniques from others.
Thanks!
People usually dont like this approach because they say it adds indirection and complexity and now they need to navigate away from the source to find where something is being done. Then we end up with methods doing too much and being really complex. Of course, we avoided indirection, but at what cost? I rather have a readable code then a clever one.
This is beautiful :)
Hello, Zoran, great video as always, I really appreciate your work as a developer! Donât you mind to suggest some of your favorite books concerning system design and architecture that helped you gain your key knowledge that you are now sharing with us? đ
I understand what you are doing, but it does seam difficult to test because of all the static functions that are created. Could you do a video on how you would test with this workflow?
Each static function is tested in isolation, and that is a regular process. The Demo class which calls them is there only for the sake of this video - no such class would exist in a production project, and therefore it would not be tested.
Yes, it is easy to understand, but is it easy to debug without a unit test, absolutely not. I usualy make sure the return value of a method is obtainable simply by putting my mouse pointer on it, the format you use make it difficult to confirm the return value is right. I suppose unit tests are a prerequisite with this style and the most efficient way to debug this kind of style is : Don't debug, write a test to find where the bug is. It would be interesting to see how you debug this kind of application or, at least, have your opinion. Thank you for these excelent and interesting videos.
I see your point, but that doesn't happen in my way of coding. First of all, I am applying a strict incremental coding technique, with application running 100% of the time. Therefore, any bug I make must show up right away, and I must have made it in the very last line of code I wrote.
When debugging complex portions of code, I rely on the console. After years of using debuggers, I settled back with the oldest of all styles.
In case that you still want to use the debugger, I would say that debuggers should be improved. For instance, Visual Studio tracks the return value for you, and you can see it on method return with no special action. Other environments and debuggers don't have such a feature, so far as I know, but I'd rather say that is an omission on their behalf.
In the long run, I expect C# to put more and more emphasis on mappings, i.e. methods that only return a value and do nothing else. We will be seeing expression-bodied methods more than ever. That urges for novel debugging methods and tools.
Hey Zoran. Love your explanation. But have a side question.
Did you ever manged to get the discount bigger then the price, đ
No. Buzz off :)
@@zoran-horvat I will never buzz off from your super clean explanations, concerning the C Sharp Language. Thanks again. Would love to talk with you. đŠđđ€âïž That's for another time. Have a good day
@@jonny.rubber I was kidding. Thank you for your support!
Discount > price == refund đ
tnx to the video! very interesting. But when you have many levels of some wrapping such as at video, your debugging is very hard. because the integrity of the understanding of what is happening is lost
you need to be able to stop
It is true that debugging is somewhat harder when object composition is applied, though even debuggers are not what they used to be. For instance, the debugger in Visual Studio has been able to report the return value from a method years ago, giving wings to expression-bodied methods.
But the greatest pitfall of only seeing the complexity where object composition is used is in failing to see that it is not a desire, but a necessity. One cannot implement a complex domain model, with hundreds of business rules, without variation built into objects. And that variation is achieved through composition of objects and composition of functions.
It hasn't clicked yet
Watch again :)
@@zoran-horvat yes, will do. Thank you sir.
Here's how OOP destroys itself, rediscovering functional programming all over again. I suppose it's a good thing, although it's only half-way there. But this example shows how functions are more readable than objects.
Functional programming is essentially a restriction upon object-oriented programming - once it matured to be applicable in business applications, rather than just in faculty exams. It was mainly accepted after understanding the errors of the past, made in object-oriented designs. However, functional programming is limited in its own ways. It is anything but the solution in itself.
Knowing that, it shouldn't come as a surprise that the best designs are attained by combining the two methods - object-oriented and functional. Neither is complete without the other.
I would agree with @piotrkozbial8753. The example you shown is an example of flawness of OOP.
You shown set of classes with IDiscount as a constructor argument and with a single method in the class. These classes are subjects to be converted to extension methods. Moreover, they can be private methods.
It is not necessary to instantiate object if you need to call a single method only. Instantiation will cause 1) memory consumption 2) CPU wasting for memory allocation + constructor execution + garbage collection. Not so efficient approach, even if constructor execution is optimized by JIT compiler.
I do agree with you @zoran-horvat, idea to express "what" instead of "how" is great! But the samples in this video are not the best choise. It looks like "we introduced a problem and now we will show how to heroically solve it" %)
I do not agree with @piotrkozbial8753 that extension methods are "rediscovering" of functional(!) programming. People name it "procedural" programming. It is even available in C language %). Yes, sintax in C will be a bit different, but it is still element of "procedural" approach.
@@zoran-horvat Please, can you make a video about OOP and FP? And how would you make it complement each other.
@@replicant9611 Many of my recent videos are on that theme, nibbling one little problem at a time. I'm not sure I can cover the topic at once, at any level of detail. The interconnectedness of all things between OOP and FP is massive.
Like as almost everything in the world, the best results are obtained by combining multiple sources
What in the name of Jesus, why are there 200 factory proxy builder cappers instead of 2 functions.
Because this is only one out of six examples that I know on top of my head in this very code base where the same capping logic applies, each time in the same way and each time in slightly different settings.
There will never be two functions, as you have put it. It would be two times N, where N is arbitrarily large and could grow to two dozens in an enterprise-grade discounts engine - as I said, 6 at the moment in a stripped-down demo version, but could easily be dozens in a production version.
I've been there more than once in my career, and I know price engines all to well. They are hands down the most complex pieces of any retail application.
The way you have put it sounds like you prefer rampant repetition of the critical piece of the financial domain logic across the application, right?