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.
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
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
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!
You are a very talented broadcaster. I’ve never seen someone talk about programming on UA-cam in such an informative and enjoyable way. Your pacing etc… is perfect. Keep at it and this channel will be huge!
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?”
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.
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 ?
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.
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'.
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.
@@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.
@@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.
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.
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.
@@mennol3885 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.
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.
@@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?
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.
@@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."
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.
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?
design patterns are never obsolete. What if you need to write the same in a language without those constructions? Or what if memory is critical and you do need iterators to avoid this? Of course using iterators in a case that does not need it is more complicated over a tradtitional array. That is a simple case of KISS. Again if you use a language with function overloading you can also make it accept iterators and arrays and the implementation of the iterator one is just a conversion to a regular array. Again: it depends which is the best solution.
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.
@@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.
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.
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.
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.
@@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.
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.
@@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 UA-camrs 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.
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.
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...
@@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
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
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
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
You should write a book on modern C# design matters!
Great content Zoran as usual
Always waiting for your videos to learn some C# internal concepts
Glad to hear you liked it!
My mindset was changed forever. Thank you!
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.
I now watch at least one video on this channel every day!
Don't overdose :)
IEnumerator is disposable, no? important to clean up usings inside of a "yield" function.
You are right, thanks for noting!
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.
Love this gentleman’s delivery, he is like Vigo Tarasov dropping OOP knowledge instead of tales of baba yaga
The outro was very nice!
Thanks for those videos, I hope to gather all the knowledge I can
I really need to start using pattern matching. C# embracing functional design is making business logic more and more readable and faster to write.
You are a very talented broadcaster. I’ve never seen someone talk about programming on UA-cam in such an informative and enjoyable way. Your pacing etc… is perfect. Keep at it and this channel will be huge!
Crystal clear explanation. 👌
NEVER watch any video where the title ends in a question mark.
Good video. I really appreciate it.
Incredible video! Thank you!
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?”
Fantastic explanation! Thanks for sharing your insights.
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.
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 ?
Thanks a lot for your explanation.
thank you for explanation, i really enjoy watch this kind of content, it makes me better as a programmer =), keep doing sir
Thanks!
Impressive, thanks for presenting this idea!
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.
Thanks for the great explanation.
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'.
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.
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.
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.
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.
@@mennol3885 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.
I learned something valuable - thank you very much!
Glad to hear it was useful!
Great video, well explained, thanks.
awesome video! thanks a lot!! :)
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.
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?
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."
Just WOW. Loved it.
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.
This video highlighted to me, the importance of the Oxford Comma.
First, second, third, and fourth.
what is c#?
... maybe I need to brush up on my C# syntax.
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?
Great content!
Thanks!
You just showed how to use a DIFFERENT design pattern than iterator!
While _still_ using iterator in the for loop.
great video
design patterns are never obsolete. What if you need to write the same in a language without those constructions? Or what if memory is critical and you do need iterators to avoid this? Of course using iterators in a case that does not need it is more complicated over a tradtitional array. That is a simple case of KISS. Again if you use a language with function overloading you can also make it accept iterators and arrays and the implementation of the iterator one is just a conversion to a regular array.
Again: it depends which is the best solution.
I want to frame this video and hang it on my wall!!! 👏👏👏👏❤❤❤❤
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.
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.
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?
Eyes opening
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.
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.
"design patterns" -- bunch of categorization for categorizations sake
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 UA-camrs 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.
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?
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?
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