Remove Messy Constructor Calls | Clean Code

preview_player
Показать описание
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.🔥❤️

⭐ Learn more from video courses:
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⭐ CONNECT WITH ME 📱👨

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
👨 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 YouTube 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.

#csharp #dotnet #objectorientedprogramming
Рекомендации по теме
Комментарии
Автор

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.

nalinsharma
Автор

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.

AlexUkrop
Автор

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!

marklord
Автор

“I don’t like to think when I’m writing code.”
That should be on a tee shirt.

paulembleton
Автор

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.

liquidpebbles
Автор

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.

ThugLifeModafocah
Автор

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? 😊

hs_cow
Автор

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?

basoli
Автор

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.

Stevedot
Автор

Hey Zoran. Love your explanation. But have a side question.
Did you ever manged to get the discount bigger then the price, 😂

jonny.rubber
Автор

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

АлексейДемин-ъж
Автор

What in the name of Jesus, why are there 200 factory proxy builder cappers instead of 2 functions.

edhahaz
Автор

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.

piotrkozbial
Автор

It's bad Design IMO. Your code lacks cohesion when you're distributing all those little parts to a decorator. It's hard to reason about interactions between decorators.

Strategy / decorator have their place when you mix data sources, put a caching layer on top, etc. It's really useful to abstract different ports and adapters.

But in your case it's just business logic and the whole decorator construct could be a single 30 line function. So it's clearly overengineered.

marcotroster