Are Design Patterns Dead in C#?
HTML-код
- Опубликовано: 13 июн 2024
- Become a patron and gain access to source code and exclusive live streams: / are-design-dead-81382714
When was the last time you implemented a proper design pattern in your object-oriented code? Not a factory method, but a proper, complex design pattern!
If it was long ago, then you are not alone. Think of all the decorators, adapters, builders, chains of responsibility, observers, states, and visitors you never made. You never made... because they were there.
This video will show you a glimpse of modern code which will incorporate no design patterns at all. And yet, it will mostly consist of design patterns. How come?
The answer is in libraries, the framework, the language syntax, in all the elements we use when writing code. Those elements are built on top of numerous patterns and they are exposing interfaces and methods that are so simple, that consuming any of these design patterns takes no more than a single method call or instantiation of a single object.
By the end of this video, you will learn that design patterns are still everywhere in our code, the same as they ever were, but that we are not responsible to implement them in most cases.
Corner cases will remain, though. If you are writing low-level library code, extensions, and frameworks, then you will likely keep implementing all those design patterns over and over again. But keep this principle in mind: implement the design patterns in your library, so that its users won't have to.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
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.🔥❤️
✅🔔 Subscribe ► / @zoran-horvat
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⭐ CONNECT WITH ME 📱👨
🌐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
For collaboration or any queries:
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
👨 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 RUclips 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 via a comment
#designpatterns #dotnet #csharp 
Наука
Become a patron and get access to source code and exclusive live streams: www.patreon.com/posts/are-design-dead-81382714
Write your thoughts about design patterns in modern business applications! I'd like to hear your opinion on the frequency and place of design patterns in your job today.
Your explanation is amazingly clear and short pauses here and there let the viewer have time to digest the content. I appreciate this video
I thought I never knew what desing patterns were, but the more I study, the more I see them in my daily life as a developer. For example, observers are used a lot in game development to manage signals and in asynchronous tasks, the Future or premise are always an observable
totally agree. i never implemented "chain of responsibilities" myself, but i do use thenby from time to time. usually development (at least for me) looks like "you just use the existing thing and only go dig the internals + implement yours, if the existing one does not work, as you want it to". having powerful means of programming, leads to that we need to have less self-made implementations for day-to-day routine
Well he is like a strict Professor who brings unique ideas and is always correct 😄. Huge respect sir !!
Thanks! I'm glad to see you liked the explanation.
My mindset was changed forever. Thank you!
The outro was very nice!
Thanks for those videos, I hope to gather all the knowledge I can
Great content Zoran as usual
Always waiting for your videos to learn some C# internal concepts
Glad to hear you liked it!
Liking this video did help others to find your videos. I'm one of the others and I'm very glad I found your channel.
Love this gentleman’s delivery, he is like Vigo Tarasov dropping OOP knowledge instead of tales of baba yaga
Another masterclass, thank you! I was hoping you would finally open up the possibility to become patreons of your channel, so you don't stop making videos!
Thank you for becoming a patron! Honestly, I wouldn't be able to run the channel without sponsorship in the long run. I appreciate your help.
I now watch at least one video on this channel every day!
Don't overdose :)
This video highlighted to me, the importance of the Oxford Comma.
First, second, third, and fourth.
You should write a book on modern C# design matters!
Thanks a lot for your explanation.
Fantastic explanation! Thanks for sharing your insights.
You are a very talented broadcaster. I’ve never seen someone talk about programming on RUclips in such an informative and enjoyable way. Your pacing etc… is perfect. Keep at it and this channel will be huge!
As always, a great video. Wouldn't you say that you have implemented the state design pattern or it's equivalent when you show the pattern matching with switch statement ?
Impressive, thanks for presenting this idea!
IEnumerator is disposable, no? important to clean up usings inside of a "yield" function.
You are right, thanks for noting!
Good video. I really appreciate it.
Thanks for the great explanation.
thank you for explanation, i really enjoy watch this kind of content, it makes me better as a programmer =), keep doing sir
Thanks!
Great video, well explained, thanks.
I really need to start using pattern matching. C# embracing functional design is making business logic more and more readable and faster to write.
The fact that you no longer need to implement the design patterns yourself does not make the Gang of Four book irrelevant for most coders. Their work is still important for you to understand what's actually happening when you use those modern language features. But yes, you should avoid rolling your own whenever possible.
Funny enough, I didn't call it irrelevant.
Crystal clear explanation. 👌
Incredible video! Thank you!
I learned something valuable - thank you very much!
Glad to hear it was useful!
Occasionally came across this video. I switched to Rust from C# but still I find this video very informative. I wondering how C# switch is now close enought to the match statement in Rust.
From what I have read on Rust, both languages now support versatile and rich patterns.
Glad i found your channel. I admit have finished almost all your tactical course series (pluralsight), so much time invested. Hope you can change your approach in a way short and straight to the point for the followers. Found similar courses same topic in lesser time to consume but same insights or lessons.
Notice how the comments are generally supportive of his style. My take is that a more complete explanation generally favaors a broader audience. You can always skip ahead in the video if you feel its too long winded.
NEVER watch any video where the title ends in a question mark.
Just WOW. Loved it.
Great video. Interested to hear if you agree that DI Containers have largely replaced Factory pattern and the combination of Generics and Extension methods largely replaces the need for visitor patterns in applications.
You are right on both accounts. I have published a video on the Visitor pattern, arguing that we don't need it in "regular" code, such as line of business applications.
DI containers are doing a great job in removing constructors from our view. Still, we must use either a constructor or some static factory method to create new instances inside operations, but as I said in the video, I do not consider that a proper design pattern. I would rather expect to see collaborators and delegation to consider a piece of code an object-oriented pattern. That is precisely the part of programming we see dying out with the advantage of libraries and the language itself.
@@zoran-horvat The need for object creation inside operations is why I was careful to say “largely”, but I do feel like Factory is so often unnecessary that I now actively try to avoid the overhead of using it. I ask myself things like “is this object creation really something I need to do at runtime, or is it really a design time solution involving DI configuration and/or scoping?”
This was a great insight :), i now realized that LINQ is using Chain Of Responsibility. It would be really helpful if you can share some more insights into the design pattern and why still many business application chose to stuck with old patterns like factory or singleton. Does one Design pattern is more relevant in todays world and others in past which are now part of legacy systems.
Possibly they don’t implement it because of high coupling in legacy code. The Chain is good when you have a clear set of rules.
@@analisamelojete1966 hmm, some of them still and i face the interview questions also
@@niteshsetin I see, this pattern is quite used in accounting software for example. There are plenty of pre-defined rules. Also, this pattern isn’t so common. In my current job, I’ve used it twice and seen it implemented once on another service.
@@analisamelojete1966 yes that make sense, accounting or finance related work
@@niteshsetin Yeah, a perfect example is paying your loan. From your monthly payment, some money goes to capital, other goes to cover interest, other goes to cover the insurance on your payment, etc etc.
I’m finding low hanging fruit on those design patterns. Suggestion….
You once asked us what design patterns interested. I’ll say more n more of us are writing state machine/workflow n in particular I’ll be researching saga/orchestration with probably mediatr as easiest to implement. That also leads people down eventual microservices, etc
People use microservices not for saga/orchestration, but more for trying to adhere to the single responsibility pattern. Saga/orchestration is a means in achieving this. Mediatr is useful for in-memory communication in a single microservice. For communication between microservices, better to abstract away and use something like event grid.
Very interesting. I did not know this is now possible in c# but when you started the list of authors I immediately thought, this must be super easy in a functional language with pattern matching - and then you did just that. I think c# really does not get the usage that it should as it started as a (more or less) Windows only language and people are still not considering it and use e.g. Java which is much worse.
I have to dig out the microscope to see the difference between Java and C#, expect Java is ubiquitous , C# not so much. In my line of coding I never come across C# code I would want to / need to use.
@@Axel_Andersen the functional syntax as shown in the video does just not exist in Java. I think it is very useful. Nothing against Java, all of my company’s apps are in Java and it works well but sometimes it does not hurt to look at other languages.
@@mudi2000a Agree with all of that. I've been programming since 1979 and do so daily so I have a quite of few languages under my belt and always try to look at new interesting ... which have been thin on the ground for late years. B
ottom line is, I guess, that the language does not matter that much, there are much more important things is programming and more importantly in business because without business there is not much that pays your bills.
I appreciate your clear explanatory style. I just want to point out you're talking about design patterns used in standard language functions like pattern-matching and LINQ, but as developers, we're usually working within our applications' business domains (where Microsoft isn't writing the code) and so still (occasionally) need to use design patterns for our domain objects. So your title is a bit misleading (maybe intentionally clickbaity?).
Nonetheless, it's really nice to have new powerful language features that simplify coding: pattern-matching is a great, simple replacement for the Visitor pattern, which is a bit complicated and not needed in most cases.
My point is that the real need to implement a design pattern in custom code is diminishing rapidly.
I am implementing an application right now, and it is quite obvious to me that the number of explicit implementations of any design pattern is by an order of magnitude less than, say, a decade or two ago. All that bloat went into expressions and libraries by now and turned into one-liners in my custom code.
@@zoran-horvat That's quite true, many things that might require design patterns can be outsourced to libraries in mature ecosystems (especially in CRUDdy business apps). I was thinking more about when architecting new systems, especially distributed ones - where architectural patterns have to be decided to lay the groundwork. But admittedly those may fall outside the scope of typical 'design patterns'.
Great content!
Thanks!
But 3 decades after this book was published people still receive peculiar questions about GoF patterns in programming interviews :)
Yes, that still happens.
for me it was on every third tech interview from last 3 months. Once me and interviewer were writing part of them from scratch...
Then you know where not to work.
@@mennovanlavieren3885 That depends on what kind of code the team is developing: In a line of business application, most patterns you need are already available in libraries and frameworks so that you don't implement any of them; if the team is developing library code, chances are much higher that there will be plenty of explicit pattern implementations.
Still, even in low-level code, so many interactions that were implemented in patterns can be delegated to lambdas and LINQ. It is the functional coding style that puts object-oriented patterns to an end.
The majority of jobs I have applied for in the past three months require that you know SOLID and Design Patterns.
great video
... maybe I need to brush up on my C# syntax.
You just showed how to use a DIFFERENT design pattern than iterator!
While _still_ using iterator in the for loop.
I'd love to hear your opinion on Singletons!
Singletons are useful to improve code readability, but I don't consider them useful as a performance optimization, let alone a guarantee that there will be no more than one instance (as GoF book suggests).
Complex objects are managed by deserialization and/or IoC containers, and so their lifetime will be specified there anyway.
If I try to remember when I used it, it was only in the most trivial cases, such as Empty or Zero static property getters defined on classes.
An important note comes to mind if one wishes to use Singleton as a performance optimization on a class that is also used to create regular instances. Static instantiation affects instance-level constructors, and so a "fast" Singleton will make all other instances of that class slower.
@@zoran-horvat What are your thoughts on singleton utility classes? Say something like generating filenames/paths from a string-template? In such a case, the utility class need not maintain any state and there is no issue if more than one "instance" exists in memory.
I want to frame this video and hang it on my wall!!! 👏👏👏👏❤❤❤❤
What about the Zip method impl without iterator?
I don't understand the question - what about Zip?
@@zoran-horvat let's say I need ZipLongest function for possibly infinite streams, but can't use MoreLINQ or other libs (strange constraint I must agree). How to implement it without enumerators?
@@user-tk2jy8xr8b I still don't understand why would you try to implement it without the iterator.
@@zoran-horvat because design patterns are dead in C#
@@user-tk2jy8xr8b Who said that they are dead?
Hey, i'm learning in java and also watching your videos, can someone explain to me please what is going on with variable "latest" at 5:07? On Design Patterns book example
Line 11 by using author.Current retrieves Erich Gamma, and in line 14 we assign author.Current value to variable "latest" (so we assign value Erich Gamma), so why when we use the variable in line 17 there is value of Richard Helm appended? When did it change?
First example, much cleaner design is to create a String.Join() with custom separator logic that does commas, puts in an "and", and so on. Throw it in your toolbox/jupyter notebook for use again and again.
Eyes opening
What about creational patters?
Factory methods are everywhere but I don't consider them a proper pattern.
Abstract factory is literally extinct today, and so is the builder. I can't remember the last time I saw one. That is the combined result of automation in domains of DI, deserialization and persistence.
Thanks to JSON, IoC containers and ORMs, we no longer create objects other than the most trivial ones.
@@zoran-horvat
"I can't remember the last time i saw one"
Funny, because you literally just used one in the video at 3:42
@@khatdubell What you are referring to is the use of the class that implements a pattern. That is quite different from referring to the code that implements it. But, let's not quote the video anymore - i believe the transcript is already telling all that.
@@zoran-horvat
You said its "literally extinct".
If they were extinct you wouldn't be able to use a class that implements them, because no classes would implement them.
Let me put this another way, by saying the pattern is "literally extinct" you're suggesting that if C# were written today it wouldn't implement the builder pattern for strings because they would use something else.
the builder pattern is very much alive and well.
@@khatdubell This conversation becomes awkward. If you press the ellipsis sign and choose Show transcript and then, in the search box, type "literally" or "extinct", you will be surprised to find that I *never* said anything of that kind in the video.
Still, I get your point. It is too picky for my taste, neglecting the bigger picture. Again, let the video transcript speak for itself:
17:14
"That doesn't mean that design patterns in business applications are dead. No! It only means that they are buried deep under the surface where you cannot see them. But you can benefit from them."
Tbh, most the design patterns in dotnet C# are handled by a properly structured sql database schema. If you structure your controllers, dto's, models, logic, and automapper correctly... everything flows fluently.
That is correct. Someone asked about creational patterns and all I could say is that I can't remember when was the last time I saw one.
@@zoran-horvat last time I saw them was when I was reading a design patterns book in java many years ago... but in the work place I have almost never seen them. There are a few rules we do follow, such as dry principle, separation of concern, and no magic numbers. But very basic stuff that everyone should know.
what is c#?
Interviewers wont ask them any more
It depends. If the programmer will need to use patterns in everyday work, then why not ask? That is a rare but legitimate case.
Take a team that develops a low-level networking library as an example. I can bet my salary that their code would be swarming with OO design patterns.
I have some doubts that man who do not program in Ada can write about good software engineering
Is there something wrong with Simula 67?
@@zoran-horvat Are there aircrafts programmed in Simula 67?
Title should be: How to make C# to seem horribly like Prolog.
At which timestamp?
@@zoran-horvat 8:55 - " This is much simpler, much easier to understand. " *NO, IT IS NOT!*
This video would be interesting if I knew how to read…
C# is such a great language. It's a shame Microsoft played dirty on other systems, buying the mono project, and preventing xamarin to exist on MacOS/Linux. Breaking the trust of developers. Otherwise it would have been one of the greatest languages in history. But now the task is up to Rust.
Be careful comparing C# to Rust. Those two languages do not address the same underlying problem.
@@zoran-horvat I agree. There is no 1 to 1 alternative to C# rn.
@@Zeioth Java and other JVM languages is a C# competitor
@@Someniatko Personally I've never been a great java supporter. Im my entire career I cannot remember a single program written in java that feels good to use.
@@Zeioth Minecraft feels solid :D
Massive clickbait
We use them all the time, don't know where he is getting his assertions from.
Clickbait is life.
This book is not for beginners, unless you understand that applying ALL the patterns in a program makes it understandable. Use them sparsely, only when it clarifies things.
An factory that only will produce one object during execution is nonsense, use new instead.
I wouldn't agree that factory is nonsense... Constructor has two disadvantages it cannot overcome: It is not assignable to a delegate and it has no return value. Factory functions are used to resolve both issues where they appear.
This video: an other zealot pushing his favorite things. Which version of his code you find more readable really depends on your background. For vast majority of programmers given their background I think the first one was more readable. Pattern matching has its place but claiming that reasoning about it is easier than reasoning about the more or less sequential code is does not hold water. Another important consideration is which one is easier to debug. I've never found a good way to debug failed patterns. Maybe cause I tend to avoid pattern matching. Which leads to the difficulty in applying them. Vicious circle I guess, but here we are.
That may be so, but I wonder - if you found the first variant more readable, then how come that you didn't see the bug it contains?
@@zoran-horvat Cause I did not go into the details. Coding is my day job, I see enough code everyday as it is so reading through RUclipsrs code in my spare time is not how I want to spend it. In fact, after 44 years programming I tend not to look at programming videos in general, cause 'I have been there done that' several times over the years... it is very rare now days to see something that is new, people are just re-inventing the wheel in programming. I looked at this because it looked like there was some new syntax in C# that I did not recall ... and there was. New to C# that is.
"design patterns" -- bunch of categorization for categorizations sake
Terrible. He doesn’t understand the meaning of the original quote. And he got the publication date of the book he’s holding off by 17 years.
GoF was published in 1994; A Pattern Language was published in 1977. Is that the 17 years you mention?
I can't do anything but dislike this video, there is no sentence more overlooked than this exact sentence:
You CAN do this solution over a million time, WITHOUT EVER doing it the same way twice.
I'm in this business for only a decade and a half and I'm just done with dogmas and religion in coding especially in the C family.
C, C++ and C# code are (among others) some of the dirtiest and less maintainable code base no matter how many patterns and good practice people try compel people to use but at the end of the day the code is still not clean but now it got so complexe it got unmaintanable. Well Done, you've just made a new tumor on the face of earth.
You should never try to force a square into a round hole, use the good tool and it will flow naturally.
Once you've said you can use the pattern everywhere over and over you've just put all close minded dev (99% of C.* devs) in a tunnel vision so that they will make crappy things for the sake of clean code for the next decade.
For example your EnumerableExtensions.intersectSorted function is just a glorified for loop, what is the real added value from simply checking your 2 arrays ?
For those who think the OOP based version with fancy interface and stuff is more reusable, a generic function would have do the exact same trick without these C# stigmas, it would have be more concise and readable but yeah the author could not brag about all the books he read to get to learn how to code a simple function...
I think we tend to complicate things because we are way stupider than we think and 50% of our daily struggle is self inflicted pain because we have to tame our new born artifical stupidity...
What do you mean that IntersectSorted is a glorified for loop? Can you show me that loop? - I'd really like to see it.
@@zoran-horvat what I mean by a glorified for loop is that you just (btw a while rather than a for) loop over your iterator until is gone you can write it a thousand different way and I am not sure the OOP is the best.
I've not made C# for a while but if you remove the class, remove the Incomparable and pass a callback as third parameter (or even use function composition) you get a very similar result without the need for any object or class creation
@@benjamin_fdw My solution does not create any objects - it is a function. And I would still love to see that loop of yours because, if it exists, then you have just invented a new algorithm. It doesn't have to be C#.
@@zoran-horvat In TS I'd go with something like this
function intersectOpt(a: T[], b: T[], comp: (x:T, y: T) => number) {
// note that I've used arrays but we could use a generator to respect the iterator principle;
// here goes a very similar code to yours but without any new class/interface/data structure, it is generic and it matches pretty much any type
}
I'm on a bad day TBH so I may sound a bit rude so I am sorry, but I spend my entire life asking for less code and less objects, because people just put their brain on stand-by and follow such advices blindly.
On the other hand the pattern matching is a nice trick but once again what makes it better than any other solution. I could bet than any other good implementation would be a pattern matching killer performance wise.
To be clear my point is "You can do this solution over a million time, by doing it the same way twice" if your point is just to reuse what the book taught you but it will be less efficient and not necessarily easier to maintain. Most of the time it will become a hellscape for you and everyone in the project because there are big chance your solution does not fit the design and as no one never remember anything it will be longer to figure out than a basic implementation.
Sorry I was writting some pseudo code and got interrupted but I will share a more complete response later on.
But, You've created an object and a static function inside it, you did not instantiate it but you stil have a new class in your project, with a static function into it.
It is not instantiated but you've still written it while it does not bring much to the project.
The implementation would be the following:
// consider T as a shorthand for Iterator
function *intersect(a: T, b: T, comp: (x: T, y: T) => number){
while(a && b && !comp(a, b)) {
const result = a;
a = a.next();
b = b.next();
yield result;
}
}
What are debate is not the quality of what you've done or saying that I can do better or anything revolutionnary but I could write this code in a million different ways in a million different scenarios and have better result than the code you've showed, not because it is better but because it is done with a purpose in mind.
I have had the same debate with a colleague that was disagreeing me using a std::function (sort of delegate in C++) rather than creating a dummy object to hold the function signature. The only argument he could make in the conversation was about OOP religion and everything should be object and I think this is because of this kind of dogmatic content that people stop using their brain when implementing a known pattern/idiom.
And it's ok to reuse s/o intelligence into your code, but you still have to use your intelligence in order to implement/integrate it the proper way
Trying to slam dunk on design patterns while using the same design patterns.
Your *_entire_* video hinges on your use of the word "explicitly".
The iterator design pattern underpins all modern programming.
Its still using it under the hood, even if you aren't using it "explicitly"
So your pattern matching example is still using iterators.
So no, they aren't dead.
Did you just quote what the video is saying?
These patterns are dead 50 yrs ago, wake up. Nobody uses them in new languages. Every system has own patterns, it is just silly idea that same things from ancient programming will work for new hardware, in new framworks with new languages.
The patterns from a 29-year-old book cannot be dead for 50 years due to a simple arithmetic contradiction.
What you are saying about "new" languages is only true in proportion to how much of the code developed in them is functional.
Compare Rust and C# as an example. The incidence of object-oriented design patterns is pretty much the same in both languages today, even though C# is some 15 years older. And the same stands for C++ which predates C# for another two decades.
It is not programming languages - it is the coding style that makes the difference.