Great tutorial. Philip made it so that you don't even have to watch the video but just listen to it instead. He walked us through the code just enough verbally. Thanks!
I love listening to Phil Japikse - great sense of humour "Off by one errors" lol. Robert Green is great too because even though he has a ton of knowledge he always asks the kinds of questions that the viewers are likely to have and puts the presenter on the spot. As others have said, the video is not entirely about SOLID but it's a valuable watch anyway and there's a lot of wisdom contained within.
This entire Series on Design Patterns is extremely helpful ... i've seen it many times now... and at every iteration i always gain some new insight or a new idea. Robert and Phil make a Great Duo at exploring these concepts.... 14:00 ... it was a good segment... haha
That man deserves a cookie! Someone, get him a cookie ASAP, You, good sir, are a clear and effective communicator, wish we had you for training at work!
One thing I dont get is why to use factories in the first place. Correct me if Im wrong but the shown example of the so called "Simple Factory" violates the OCP principle because everytime I add a new Type of pizza I have to create a new class for it and then modify the factory class to be able to create an instance of the new class through the factory and I also need to create a new entry in the PizzaType Enum. Can somebody explain this to me
Around 24:00 ... single responsibility principle? Whenever you want to add new type of pizza, you have to modify class factory. What if you want to have BetterPizzas.dll containing several new types? Isn't it better to include class factory into possibly several files and register all available PizzaFactories and their IDs from outside during program initialization?
Viewers are having fun. These are the conversations that are so interesting and rare as everyone is either so busy or afraid to discuss because they may not know as much and might look less competent. Debate everything on these videos! Please :)
Also a Contrasting Comparison of Code with and without these patterns as suggested by Robert at 55:00 would be a Great Idea... may be a git repository with both kind of codes .... would answer so many questions and deliver the reason behind these patterns as well.
Only thing about the decorator: if you don't know (or in this case, the ICar doesn't know/care) what you have already done, how to you enforce certain boundaries? I don't want to "armor the car" a couple of times and suddenly have negative speed...
I watch many video's on this channel, but this one piqued my interest only to let me down. Too much about design patterns and not enough SOLID information. Also, it felt like Robert was lost most of the time like many people I'm sure that were trying to follow along. But the details were glossed over, and the reasons for doing the patterns were difficult to understand. I think this was mostly because he was trying to cram too much information in too short a time. This would have been better had it been broken up into multiple videos with more time dedicated to each pattern and how that patterns helps make SOLID code.
In real-world application development, everything is a tradeoff and he is using his experience to touch those boundaries. If all you want to do is learn SOLID designs without becoming aware of its tendency to become bloat wear look elsewhere...
This video in itself violated the Single Responsibility Principle which is very ironic. Trying to do too much in a single video. Like he said with regards to the number of files in a project "so what?!" if you end up with many videos. Break this down into single topics.
Uncle Bob does this better. He keeps my attention and he's so clear why we need to adhere to SOLID. I'm currently refactoring a monolithic 8000 lines of code written by a mathematician. It's been hacked to death by two others so far "code rot". Down to 4600 lines in 3 days. Don't let maths guys write code
Great video. It give me a basic understanding of the different design patterns. I would also be interested in watching the follow up video that refactors code into a design pattern.
Just a warning to future viewers because this wasn't clear to me: Only about 10 minutes of the video is actually about the SOLID principles directly. The majority of the video focuses on OOP design patterns and how they can be used to implement the SOLID principles. It actually says this in the video description but the title of the of video was misleading.
I do not think the Service vs Inversion was answered. They seem the same. They all use, somewhere, the "real" implementation which is based on the Interface contract or an Abstract class.
I really liked the talk, but where are the next parts? Robert mentioned a future refactoring talk. I would definitely read Head First Design Patterns, like Philip said, to understand the language of the seniors devs.
I really liked the show, but I'm dissapointed that I can't find related videos in one place, I have to check it on TH-cam. 14:31 is why you need to understand SOLID principles In 27:27 Philip explains why he uses easy examples instead of complex ones
I understand the idea and the reason for using design patterns, there are some stuff I got lost, but I will review the book you recomnend. I find it hehe video useful because of the examples like what happens if I the card provider have different methods or if I have to change price in production without releasing a new version, that is where I find that implementing design patterns is a game changer, I have heard about them but I never feel like I was going to need them, I also thought it is over killing the project, but the example of the decorator pattern brings maintainability, instead of creating new classes for each possibility, I wouldn't realize that before if I wasn't watched this video. Thanks for the insight about design patterns, hope you have done the examples with the old school way and the design pattern way.
Simple Factory - makes no sense. I guess that is why the Gang of Four did not mention it. What do you gain from a factory method? "I want to have one place where I create. I don't want to create from multiple places " - why??? You might as well call the constructor directly wherever you need to create the object.. The proper answer is that you want to avoid dependency. You are looking to solve this with an inversion of control. In this case, you are employing a separate factory. Hence, if the CEO asks you to change the "new CreditCardA()" to "new CreditCardB()" - you don't need to touch the [sensitive] Client. Rather, you just modify the factory class/function.
Because if you add new type you would have to modify every switch/if statement where you use to create objects its just so you minimize if statetements for creating objects to one and only place. Simple factory is made for one family of object where you would use factory method for multiple families of object like the example for diffrent pizza stores. You are right on the money with dependencies.
"Because if you add new type you would have to modify every switch/if statement where you use to create objects its just so you minimize if statetements for creating objects to one and only place" - that's called "don't repeat yourself". It is not a "creational" design pattern.
I agree that he's full of nonsense. But the question that he is raising - about the change of credit card 💳 - is a good one. Resolving the dependency on a concretion by inversion of control - like dependency injection - is a good solution. But his jumping to the example of the"moose and flying squirrel" - is the problem. It's a terrible example when u have the credit card example staring at your face.
This could have been SO much better if they spent a little more time in the editing room adding watermarks, flyovers, or anything to show transitions between the principles and which patterns implemented which principles.
I've seen old C++ projects with huge relational diagrams based on classes that have been inherited and inherited and inherited. Not pretty, this pattern seems to be heading in the same direction!
Very good video about how to become good developer. the Clean Code is best one of my favorite books. especialy boy scout principle is very helpful to me to make software better than before.
Exactly, I don't understand why anyone would ev3n stop at 2 things. I personally like to put the entire program into public static main. All the code conveniently located in one location.
The example with chganging the bit on tap in a bar made me smile, that cab somtimes depend on hu suplies the beeer, if yhe suplyier owns the taps and the thanks (yes this sometimes happens) you can’t changes to beer firm another suokier/ producer as you will incur custs when your current suplier comes and tekaes ther taps, raks ans compressor back. sorry if this was ot grat video
I Love what you guys are doing..., giving those of us that are fairly new to programming a way of understanding how to program beyond an understanding of an introduction to C#. However, it would be nice if you think of the Newbie, when you say "The Goal is not to bend developers to the will of some Specific Pattern, but to get them to think about what they are doing" the Phil Haack quote, that should not be directed at Newbies because some one new to Programming may understand the basics of the C# or whatever language, but may not have any Idea of how to Structure their code to good effect. Having a good understanding of the various patterns out there..., especially the Gang of Four Patters provides a baseline for Developing code. Only after understanding the Basic Design Patterns can a Programmer be in a Position to "Think about what they are doing" in a way that adds value... Anyway as a Newbie, I just wanted to share this view with you guys. Please keep helping us New Programmer become good at our craft and focus on us at least as much as you do the choir..., those that already know the concepts you are sharing... Tim (Retired Navy; New Programmer...)
OMG, you explained what was there well enough, but... lock (_syncLock) return x ?? (x = new MySingletonClass()); / not the point of the exercise, I don't think, but you see the difference...
Came across another one recently, DAMP. Descriptive and Meanful Phrases. Made me laugh.
7 ปีที่แล้ว
Good that the show owner asked specific questions about SOLID, is not easy to understand, why people pass so fast to it when they are explained? I wished they had not stopped discussing about real examples.
I know this is a year late... If you're still curious, Tim Corey has a great video on interfaces. He also has one on the Liskov Substitution Principle.
Great talk, but this video lacks one thing. He talks about things but doesn't show the code (0:00-20:00). He speaks the code outloud and you can imagine it, but looking at it and make changes to it to show what's going on would change my rating of it from 7/10 to 10/10. Little, though very important detail. I really like the video anyway. A bit too chaotic but a good one.
I stopped after the SOLID discussion because I didn't find it very useful or good. He blew through the names in the list very quickly, and did not use their full names when he did, and didn't explain that their first letters is where SOLID comes from. He could have simply laid out a nice, full visual similar to this (but better formatted than I do here). S = SRP = Single Responsibility Principle O = OCP = Open Closed Principle L = LSP = Liskov Substitution Principle I = ISP = Interface Segregation Principle D = DIP = Dependency Inversion Principle His description of LSP was not right: it's not "program to interfaces". He didn't explain the main problems that ISP is meant to solve - it's not just that interfaces are too big, there are problems with IMPLEMENTING large interfaces. So you don't really know WHY you should use ISP. His discussion of DIP was all over the place. I think someone unfamiliar with SOLID would miss out on a lot of simple things, whereas someone already familiar with SOLID would not learn anything new.
"pretend the next person looking at your code is an axe wielding psychopath ... in reality who is looking at your code next is probably you" I would not see that as a contradiction :-D
6:52 - Why did they even bring this guy in if he's not a beer expert? j/k i love this guy lol. I also suspect he knows more about beer than he's letting on.
I'm a little unclear how 'programming to an interface', described in the Liskov Substition Principle discussion, differs from Dependency Injection in Phil's explanation.
Adapter - the example with the Moose and FlyingSquirl has nothing to do with Adapter. Instead - the purpose of the adapter is to allow two (a ClientA and a ServerB) PRE-WRITTEN / tested / proven / signed classes to interact WITHOUT making code modifications. Even though they can't - because the ClientA is unaware of the ServerB. Instead, ClientA is designed for ServerA. Solution: Adapter Pattern. We build a new ServerA2 that looks identical (in the eyes of ClientA) as ServerA. ServerA2 is aware of ServerB and actually exposes its functionality to ClientA.
There are different types of adapters. What was presented here was just one of the few that are common. You should do your reading before acting all high and mighty just because you learned about one thing, and didn't even learn it properly.
+Assaf Wodeslavsky How about you actually try reading your link to wikipedia. You're not going to retract because you have too much pride, which is already made evident with you trying to act smart and giving me a link that you haven't even read for yourself. Here are some texts for you to read for descriptions and examples of Adapters being put to use: Design Patterns: Elements of Reusable Object-Oriented Software Agile Principles, Patterns, and Practices in C# Clean Code: A handbook of Agile Software Craftsmanship
I've included 3 books in my previous comment if you know how to click on the 'Read more'. I don't need to show links, stop being lazy and read. I'm not here to spoon feed you - heck, you're not even going to open your mouth even if I was going to spoon feed you.
Idealistic BS, these guys never seen real code I guess...SOLID, Design Patterns all is taken backwards today and use whether is beneficial or not. Back in the days we created such solutions called today design patterns and we used them only there where was needed. Today programmers start with design pattern instead of even thinking....
LOL... dependency injection the guy talks about a logging warning level. He should have referenced a MUP or driver framework or changing the destination of logging from file to debug out to a web site etc... ugh Also, the short code example he's showing at 20:42 is n00b. He checks for _instance OUTSIDE the lock and then again INSIDE the lock. He only needs it inside the lock. The benefit of having it outside only serves one purpose and that purpose is the exception to a singleton's use as opposed to the rule. He should have referenced 80/20 as a pattern.
SOLID is a set of Design Principles, not Design Patterns! Do not create confusion. You do not have to make BS videos if you can't get the basics right!
This co host constantly interrupts this dude at every important point. To the point that he simply not make a any consistent or meaningful explanations I would of told him to follow the pattern that he needed to apply the STFU pattern.
What a garbage was to implement a singleton. Constructors are automatically threadsafe for starters... You make a static get()... static Singleton& get(){ static Singleton _instance = Singleton(); return _instance; } It will only be initialized a single time, you make a private constructor, everytime after that it only returns _instance. No need for all that other shit.
14:31 "If you are writing something 3 times you might want to stop being a developer" LOL I died.
For a little context, he was talking about repeated (i.e. non-DRY) code, and with that, I also died. 😋
Great tutorial. Philip made it so that you don't even have to watch the video but just listen to it instead. He walked us through the code just enough verbally. Thanks!
I love listening to Phil Japikse - great sense of humour "Off by one errors" lol. Robert Green is great too because even though he has a ton of knowledge he always asks the kinds of questions that the viewers are likely to have and puts the presenter on the spot. As others have said, the video is not entirely about SOLID but it's a valuable watch anyway and there's a lot of wisdom contained within.
This entire Series on Design Patterns is extremely helpful ... i've seen it many times now... and at every iteration i always gain some new insight or a new idea. Robert and Phil make a Great Duo at exploring these concepts.... 14:00 ... it was a good segment... haha
Most of us are janitors!!! SO TRUE!!
That man deserves a cookie! Someone, get him a cookie ASAP, You, good sir, are a clear and effective communicator, wish we had you for training at work!
Hamza, I am available for training. We should discuss. Thank you for the kind words!
14:00 was good, wish they didnt stop. Seems too often I have the same argument in the office.
The link to the code samples in the description is dead... they can be found on GitHub here:
github.com/skimedic/presentations
This is the video I have been waiting for. Every developer must see this. Thanks a lot Microsoft
One thing I dont get is why to use factories in the first place. Correct me if Im wrong but the shown example of the so called "Simple Factory" violates the OCP principle because everytime I add a new Type of pizza I have to create a new class for it and then modify the factory class to be able to create an instance of the new class through the factory and I also need to create a new entry in the PizzaType Enum. Can somebody explain this to me
We're just "janitors". Brutal and honest truth.
Around 24:00 ... single responsibility principle? Whenever you want to add new type of pizza, you have to modify class factory. What if you want to have BetterPizzas.dll containing several new types? Isn't it better to include class factory into possibly several files and register all available PizzaFactories and their IDs from outside during program initialization?
Just in case anyone is wondering the plural of moose is just moose.
I had no idea Steve Carell had a Visual Studio show.
lol i see it now.
lol
love the back and forth between you two, great asides
Viewers are having fun. These are the conversations that are so interesting and rare as everyone is either so busy or afraid to discuss because they may not know as much and might look less competent. Debate everything on these videos! Please :)
link to the Code doesnt work. can you update it? ty
I couldn't find the source code on link , can you please share it on somewhere else ? source code looks rather instructive.
Thank you for the discussion at around 10 minutes on abstraction. That was great!
So, what was dubbed "SOLID design patterns" turned into "design patterns". Hmm...
“The three hardest things in software development are naming conventions and off-by-one errors” - I bet that is not his but pretty good.
Also a Contrasting Comparison of Code with and without these patterns as suggested by Robert at 55:00 would be a Great Idea... may be a git repository with both kind of codes .... would answer so many questions and deliver the reason behind these patterns as well.
what is the best design pattern?
Would think that IPizza wouldn’t have cut, bake, or box within it...following the single responsibility + general OOP principles
I agree, it also has properties on it which I think should be in an abstract pizza class.
Just wonder why he put properties on the interface which he could put it in an abstract base class.
Only thing about the decorator: if you don't know (or in this case, the ICar doesn't know/care) what you have already done, how to you enforce certain boundaries? I don't want to "armor the car" a couple of times and suddenly have negative speed...
This is jumping ALL over the place!!!!!
Love the explanations and detail in this video!
Was there ever a follow up episode where they had examples of the "not optimal" way of coding?
I watch many video's on this channel, but this one piqued my interest only to let me down. Too much about design patterns and not enough SOLID information. Also, it felt like Robert was lost most of the time like many people I'm sure that were trying to follow along. But the details were glossed over, and the reasons for doing the patterns were difficult to understand. I think this was mostly because he was trying to cram too much information in too short a time. This would have been better had it been broken up into multiple videos with more time dedicated to each pattern and how that patterns helps make SOLID code.
In real-world application development, everything is a tradeoff and he is using his experience to touch those boundaries. If all you want to do is learn SOLID designs without becoming aware of its tendency to become bloat wear look elsewhere...
You may want to go over to Christopher Okhravi's YT channel and pick up on the SOLID and Design Patterns playlists.
This video in itself violated the Single Responsibility Principle which is very ironic. Trying to do too much in a single video. Like he said with regards to the number of files in a project "so what?!" if you end up with many videos. Break this down into single topics.
Uncle Bob does this better. He keeps my attention and he's so clear why we need to adhere to SOLID. I'm currently refactoring a monolithic 8000 lines of code written by a mathematician. It's been hacked to death by two others so far "code rot". Down to 4600 lines in 3 days. Don't let maths guys write code
Great video. It give me a basic understanding of the different design patterns. I would also be interested in watching the follow up video that refactors code into a design pattern.
code samples gone!!!
Just a warning to future viewers because this wasn't clear to me: Only about 10 minutes of the video is actually about the SOLID principles directly. The majority of the video focuses on OOP design patterns and how they can be used to implement the SOLID principles. It actually says this in the video description but the title of the of video was misleading.
I actually really appreciated him pushing back on DI
I think header should be something like SOLID & Common Design Pattern. I was here and thought I would have SOLID all they way.
I do not think the Service vs Inversion was answered. They seem the same. They all use, somewhere, the "real" implementation which is based on the Interface contract or an Abstract class.
I really liked the talk, but where are the next parts? Robert mentioned a future refactoring talk.
I would definitely read Head First Design Patterns, like Philip said, to understand the language of the seniors devs.
What is the purpose of _naming?
Edit:
I am referring to: _instance (at 20:45 for instance)
Seems like it's used for members to differentiate them from parameters and local variables. We are using m_name, I've seen name_ in some code.
I really liked the show, but I'm dissapointed that I can't find related videos in one place, I have to check it on TH-cam.
14:31 is why you need to understand SOLID principles
In 27:27 Philip explains why he uses easy examples instead of complex ones
Moose plural is Moose, ajajjaj. I google it.
I learned a lot with you guys. You're awesome.
whether this code is available in github? If so link please.
Should do one *only* on SOLID principles. This was good but a bit too much interruption at places for my liking. Keep up the good work.
I understand the idea and the reason for using design patterns, there are some stuff I got lost, but I will review the book you recomnend. I find it hehe video useful because of the examples like what happens if I the card provider have different methods or if I have to change price in production without releasing a new version, that is where I find that implementing design patterns is a game changer, I have heard about them but I never feel like I was going to need them, I also thought it is over killing the project, but the example of the decorator pattern brings maintainability, instead of creating new classes for each possibility, I wouldn't realize that before if I wasn't watched this video. Thanks for the insight about design patterns, hope you have done the examples with the old school way and the design pattern way.
One of the best explanations I've heard.
I think we can better explain these concepts with real life simple examples instead of funny/cartoony ones.
Phil explains that choice in the video.
Good talks Sirs. It is very helpful. Thanks a lot! I'm looking forward to see the follow up show, the refractoring. :)
Simple Factory - makes no sense. I guess that is why the Gang of Four did not mention it. What do you gain from a factory method? "I want to have one place where I create. I don't want to create from multiple places " - why??? You might as well call the constructor directly wherever you need to create the object.. The proper answer is that you want to avoid dependency. You are looking to solve this with an inversion of control. In this case, you are employing a separate factory. Hence, if the CEO asks you to change the "new CreditCardA()" to "new CreditCardB()" - you don't need to touch the [sensitive] Client. Rather, you just modify the factory class/function.
Because if you add new type you would have to modify every switch/if statement where you use to create objects its just so you minimize if statetements for creating objects to one and only place. Simple factory is made for one family of object where you would use factory method for multiple families of object like the example for diffrent pizza stores. You are right on the money with dependencies.
"Because if you add new type you would have to modify every switch/if statement where you use to create objects its just so you minimize if statetements for creating objects to one and only place" - that's called "don't repeat yourself". It is not a "creational" design pattern.
Assaf Wodeslavsky It still is some sort of a pattern because it is widely used.
Yes - it is called - "a function".
I agree that he's full of nonsense. But the question that he is raising - about the change of credit card 💳 - is a good one. Resolving the dependency on a concretion by inversion of control - like dependency injection - is a good solution. But his jumping to the example of the"moose and flying squirrel" - is the problem. It's a terrible example when u have the credit card example staring at your face.
Liskov is only notional on the CLI
Who came here after getting frustrated with uncle Bob not getting past O of SOLID.
same here. he was talking water too much
thanks for explaining by Phil and Robert for a\ such a important topic in software programing
Excelent questions by Robert.
The mapping stuff at 33 minutes seems really harmful. Would be very confusing to encounter.
This could have been SO much better if they spent a little more time in the editing room adding watermarks, flyovers, or anything to show transitions between the principles and which patterns implemented which principles.
I've seen old C++ projects with huge relational diagrams based on classes that have been inherited and inherited and inherited. Not pretty, this pattern seems to be heading in the same direction!
I actually really enjoyed the off-by-one joke ;)
Very good video about how to become good developer.
the Clean Code is best one of my favorite books.
especialy boy scout principle is very helpful to me to make software better than before.
2:38 this is gold!
not once everytime i feel oh man how can they wrote in this manner but finally checking commit history :P the name looks very familiar :)
Can anyone write a C program without using semi colon anywhere... Just a Hello world program... no semi colon
Why would you write a method that does 2 things?
Exactly, I don't understand why anyone would ev3n stop at 2 things. I personally like to put the entire program into public static main. All the code conveniently located in one location.
So... thinking of it like functional programming, but not?
The example with chganging the bit on tap in a bar made me smile, that cab somtimes depend on hu suplies the beeer, if yhe suplyier owns the taps and the thanks (yes this sometimes happens) you can’t changes to beer firm another suokier/ producer as you will incur custs when your current suplier comes and tekaes ther taps, raks ans compressor back. sorry if this was ot grat video
I Love what you guys are doing..., giving those of us that are fairly new to programming a way of understanding how to program beyond an understanding of an introduction to C#. However, it would be nice if you think of the Newbie, when you say "The Goal is not to bend developers to the will of some Specific Pattern, but to get them to think about what they are doing" the Phil Haack quote, that should not be directed at Newbies because some one new to Programming may understand the basics of the C# or whatever language, but may not have any Idea of how to Structure their code to good effect. Having a good understanding of the various patterns out there..., especially the Gang of Four Patters provides a baseline for Developing code. Only after understanding the Basic Design Patterns can a Programmer be in a Position to "Think about what they are doing" in a way that adds value... Anyway as a Newbie, I just wanted to share this view with you guys. Please keep helping us New Programmer become good at our craft and focus on us at least as much as you do the choir..., those that already know the concepts you are sharing... Tim (Retired Navy; New Programmer...)
7:42 - Maibock, yeah that's the beer I was thinking of.
Very good and very easy to listen to.
OMG, you explained what was there well enough, but... lock (_syncLock) return x ?? (x = new MySingletonClass()); / not the point of the exercise, I don't think, but you see the difference...
The anti-pattern, antithesis of DRY, or W.E.T., We Enjoy Typing. Been there, seen that, try to avoid it at all costs.
Came across another one recently, DAMP. Descriptive and Meanful Phrases. Made me laugh.
Good that the show owner asked specific questions about SOLID, is not easy to understand, why people pass so fast to it when they are explained? I wished they had not stopped discussing about real examples.
Interface what? I come from this background and I'm not sure that wasn't a clumsy anecdotal illustration.
I know this is a year late... If you're still curious, Tim Corey has a great video on interfaces. He also has one on the Liskov Substitution Principle.
Great talk, but this video lacks one thing. He talks about things but doesn't show the code (0:00-20:00). He speaks the code outloud and you can imagine it, but looking at it and make changes to it to show what's going on would change my rating of it from 7/10 to 10/10. Little, though very important detail.
I really like the video anyway. A bit too chaotic but a good one.
I stopped after the SOLID discussion because I didn't find it very useful or good.
He blew through the names in the list very quickly, and did not use their full names when he did, and didn't explain that their first letters is where SOLID comes from. He could have simply laid out a nice, full visual similar to this (but better formatted than I do here).
S = SRP = Single Responsibility Principle
O = OCP = Open Closed Principle
L = LSP = Liskov Substitution Principle
I = ISP = Interface Segregation Principle
D = DIP = Dependency Inversion Principle
His description of LSP was not right: it's not "program to interfaces".
He didn't explain the main problems that ISP is meant to solve - it's not just that interfaces are too big, there are problems with IMPLEMENTING large interfaces. So you don't really know WHY you should use ISP.
His discussion of DIP was all over the place.
I think someone unfamiliar with SOLID would miss out on a lot of simple things, whereas someone already familiar with SOLID would not learn anything new.
"pretend the next person looking at your code is an axe wielding psychopath ... in reality who is looking at your code next is probably you" I would not see that as a contradiction :-D
6:52 - Why did they even bring this guy in if he's not a beer expert?
j/k i love this guy lol. I also suspect he knows more about beer than he's letting on.
I'm a little unclear how 'programming to an interface', described in the Liskov Substition Principle discussion, differs from Dependency Injection in Phil's explanation.
Thank you, Microsoft.
53:41 the cheese is making him hungry
Janitor here 😃
love this thank you
The guy in the white shirt always asks the same questions I have.
Ok, mh. Thanks.
اذا امكن ترجمة المقاطع للغة العربية .
This guy looks like Michael Scott's brother
15:06
LMAO, this guy is hilarious. The three hardest things in Software development.
That first test he shows is sort of funny? If Assert.AreSame does not fail then the remaining asserts are pointless.
I'm about 2 programming languages late lol Thanks +1!
Pleased I found this video.
what weird analogies :/ the dude is mixing dependency injection with dependency inversion...
A poor man's Uncle Bob
Adapter - the example with the Moose and FlyingSquirl has nothing to do with Adapter.
Instead - the purpose of the adapter is to allow two (a ClientA and a ServerB) PRE-WRITTEN / tested / proven / signed classes to interact WITHOUT making code modifications. Even though they can't - because the ClientA is unaware of the ServerB. Instead, ClientA is designed for ServerA. Solution: Adapter Pattern. We build a new ServerA2 that looks identical (in the eyes of ClientA) as ServerA. ServerA2 is aware of ServerB and actually exposes its functionality to ClientA.
There are different types of adapters. What was presented here was just one of the few that are common. You should do your reading before acting all high and mighty just because you learned about one thing, and didn't even learn it properly.
i'd be happy to retract, if you show me your sources. in wikipedia, i only found one adapter pattern. en.wikipedia.org/wiki/Adapter_pattern
+Assaf Wodeslavsky
How about you actually try reading your link to wikipedia.
You're not going to retract because you have too much pride, which is already made evident with you trying to act smart and giving me a link that you haven't even read for yourself.
Here are some texts for you to read for descriptions and examples of Adapters being put to use:
Design Patterns: Elements of Reusable Object-Oriented Software
Agile Principles, Patterns, and Practices in C#
Clean Code: A handbook of Agile Software Craftsmanship
98luk45 1. please stop attacking my person. 2. Please include a link and a quote from said link, supporting your position.
I've included 3 books in my previous comment if you know how to click on the 'Read more'. I don't need to show links, stop being lazy and read. I'm not here to spoon feed you - heck, you're not even going to open your mouth even if I was going to spoon feed you.
get{ if (_instance == null){ lock (_syncLock){ _instance = new MySingletonClass(); } } return _instance; }
Wish the other guy would stop saying "Ok", "Aha..."
talk about design principles next time
Idealistic BS, these guys never seen real code I guess...SOLID, Design Patterns all is taken backwards today and use whether is beneficial or not. Back in the days we created such solutions called today design patterns and we used them only there where was needed. Today programmers start with design pattern instead of even thinking....
GPL best
LOL... dependency injection the guy talks about a logging warning level. He should have referenced a MUP or driver framework or changing the destination of logging from file to debug out to a web site etc... ugh
Also, the short code example he's showing at 20:42 is n00b. He checks for _instance OUTSIDE the lock and then again INSIDE the lock. He only needs it inside the lock. The benefit of having it outside only serves one purpose and that purpose is the exception to a singleton's use as opposed to the rule. He should have referenced 80/20 as a pattern.
SOLID is a set of Design Principles, not Design Patterns! Do not create confusion. You do not have to make BS videos if you can't get the basics right!
This co host constantly interrupts this dude at every important point. To the point that he simply not make a any consistent or meaningful explanations I would of told him to follow the pattern that he needed to apply the STFU pattern.
What a garbage was to implement a singleton. Constructors are automatically threadsafe for starters... You make a static get()...
static Singleton& get(){
static Singleton _instance = Singleton();
return _instance;
}
It will only be initialized a single time, you make a private constructor, everytime after that it only returns _instance. No need for all that other shit.
You guys have to keep this vids for under 30 mins. No one has an hour.