Latest / DevQuestions with Tim Corey / 005 How Do I Learn Design Patters? Which Design Patterns Should I Know?

Transcript

005 How Do I Learn Design Patters? Which Design Patterns Should I Know? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_00: Now here's your host, expert developer and online educator, Tim Corey.
• 0:25
  SPEAKER_01: Understanding design patterns can be a tricky subject.
• 0:28
  SPEAKER_01: Should you learn all the design patterns?
• 0:30
  SPEAKER_01: How many are there?
• 0:32
  SPEAKER_01: Is it good to apply all the design patterns to your code?
• 0:35
  SPEAKER_01: Which ones are important, which ones aren't?
• 0:37
  SPEAKER_01: What about the gang of four?
• 0:39
  SPEAKER_01: These kind of questions I get a lot.
• 0:42
  SPEAKER_01: So in this video, I'm going to answer those questions.
• 0:45
  SPEAKER_01: So if you don't know me, my name is Tim Corey and my goal is to make learning C sharp easier.
• 0:50
  SPEAKER_01: And sometimes that means taking a break from writing code and talking about the code so you have a better understanding of what's going on and why you should do what you do.
• 1:01
  SPEAKER_01: So if you're interested in videos like this, there's a whole playlist for these dev questions.
• 1:06
  SPEAKER_01: And I also have playlists for other topics as well, as getting started in C Sharp and data access and so on.
• 1:13
  SPEAKER_01: Check them all out.
• 1:14
  SPEAKER_01: Also make sure you hit the subscribe button to subscribe.
• 1:17
  SPEAKER_01: Now, if you also have any questions that you think might be a great question for the dev question series, leave it down in the comments below and I'll be sure to add it to the list.
• 1:27
  SPEAKER_01: If you have questions you want to see answered in code format, leave those questions as well.
• 1:32
  SPEAKER_01: I'll put it on the list.
• 1:33
  SPEAKER_01: Okay?
• 1:34
  SPEAKER_01: So let's talk about design patterns.
• 1:36
  SPEAKER_01: Now, one of the things that is a little bit frustrating for me, and it's not anybody's fault, at least not the learner's fault, but one of the things that frustrates me is that people that are just starting out are told you need to learn all these design patterns.
• 1:55
  SPEAKER_01: And it makes the barrier to entry for C very, very high.
• 2:00
  SPEAKER_01: And here's the deal: you can write good code, you can write great code without using design patterns.
• 2:08
  SPEAKER_01: Now, you need to write design patterns at some point, but your code doesn't have to have those patterns yet.
• 2:18
  SPEAKER_01: Learn how to write code.
• 2:20
  SPEAKER_01: Because the very first thing about a C application, the thing that separates it good from bad, is does it do the job it was intended to do?
• 2:29
  SPEAKER_01: If it does, it passes that test, it's a good application.
• 2:33
  SPEAKER_01: Could it be better?
• 2:34
  SPEAKER_01: Sure.
• 2:35
  SPEAKER_01: But that doesn't mean it's not a good application.
• 2:38
  SPEAKER_01: So take a step back and don't get overly concerned about design patterns.
• 2:43
  SPEAKER_01: Now, with that, don't just stop there because design patterns do have a very important role in software development.
• 2:53
  SPEAKER_01: They allow us to kind of have this ready-made pattern, ready-made design to put into our code to make it better in some way, hopefully.
• 3:05
  SPEAKER_01: Now, I often encourage people to start, if you want to start down this path, and this is a more advanced path, so don't start it when you're just starting to learn C sharp.
• 3:16
  SPEAKER_01: But once you're kind of ready, once you're at that intermediate to maybe even starting to think about advanced level, at least intermediate though, level of knowledge of C sharp, then I suggest starting with dry.
• 3:30
  SPEAKER_01: It's not a pattern, it's a principle.
• 3:33
  SPEAKER_01: Okay, so what's the difference between a pattern and a principle first?
• 3:37
  SPEAKER_01: A pattern is a specific do it this this way in this language.
• 3:44
  SPEAKER_01: A principle is a a guiding factor.
• 3:48
  SPEAKER_01: Okay, so dry, the guiding factor is don't repeat yourself.
• 3:54
  SPEAKER_01: So if you find yourself writing the same code for the same reason more than one time, that's a good time to think about how I can refactor that code.
• 4:05
  SPEAKER_01: That's an both an easy and a hard way to do your first pattern, your first principle, because it's easy to spot those things.
• 4:15
  SPEAKER_01: It can be a little bit more tricky to learn how to start implementing.
• 4:18
  SPEAKER_01: So that's a great place to start because it's easy to spot.
• 4:22
  SPEAKER_01: And then after that, I recommend the SOLID principles.
• 4:26
  SPEAKER_01: Again, principles.
• 4:27
  SPEAKER_01: And even there, there's five principles in SOLID, SOLID.
• 4:32
  SPEAKER_01: Um, each one is an acronym for a um for actually for an acronym.
• 4:37
  SPEAKER_01: So we have the single responsibility principle, the open-close principle, list cost substitution, the um I'm drawing a blank on I, um, and dependency inversion principle.
• 4:49
  SPEAKER_01: I'll think about it.
• 4:51
  SPEAKER_01: Um interface segregation principle.
• 4:53
  SPEAKER_01: There we go.
• 4:53
  SPEAKER_01: Um that's the I, and then D is dependency inversion, not dependency injection.
• 4:58
  SPEAKER_01: So those five principles, they're they kind of work as a team, but at the same time, you can pull some of them out.
• 5:06
  SPEAKER_01: So I usually say start with S, start with single responsibility principle.
• 5:11
  SPEAKER_01: When you're writing a method or a class, especially a method, make sure it does one thing, not two things, not three things, not four things, which is often the place where newer developers get stuck, is they write this massive block of code that does everything.
• 5:28
  SPEAKER_01: And it works, and that's awesome.
• 5:30
  SPEAKER_01: You did a great job, you got something working.
• 5:32
  SPEAKER_01: The next level in your programming means make SRP a thing in your code where a method does one thing.
• 5:43
  SPEAKER_01: And then once you got through that, then think about maybe the end one D, which is dependency inversion, which usually takes the practical implementation view of dependency injection.
• 5:58
  SPEAKER_01: Okay, I have videos on these.
• 5:59
  SPEAKER_01: So if you want to check out my dry video or my solid videos, you'll see these things, as well as a video on dependency injection.
• 6:07
  SPEAKER_01: So these are principles, not patterns.
• 6:11
  SPEAKER_01: They kind of go in the same category.
• 6:14
  SPEAKER_01: Um, because a principle just applies as an overall idea to your code.
• 6:20
  SPEAKER_01: You have to figure out how to actually make it work.
• 6:23
  SPEAKER_01: But a pattern is something that is pretty prescriptive.
• 6:29
  SPEAKER_01: Here's what you do.
• 6:30
  SPEAKER_01: Okay, so I recommend starting with principles, and those are the principles I recommend, and even there's the order I recommend.
• 6:37
  SPEAKER_01: So first dry, then SRP, then uh dependency inversion principle or dip.
• 6:43
  SPEAKER_01: I love that acronym.
• 6:45
  SPEAKER_01: Um, and then go back and look at the other solid principles.
• 6:50
  SPEAKER_01: Now, before we go further and talk about the Gang of Four and others, um, let's stop for a minute and talk about even what I've talked about so far.
• 7:01
  SPEAKER_01: These things are, if you're not careful, dangerous to your code.
• 7:07
  SPEAKER_01: And it may sound like, well, Tim, these are good things, right?
• 7:09
  SPEAKER_01: So therefore, I must be able to apply all of them to my code.
• 7:13
  SPEAKER_01: And the answer is not necessarily no, because you can over-engineer your application.
• 7:20
  SPEAKER_01: If I'm gonna write a small hello world application, I'm not gonna apply uh solid.
• 7:28
  SPEAKER_01: I'm not gonna apply any design patterns, probably.
• 7:31
  SPEAKER_01: I'm not going to even necessarily apply dry.
• 7:34
  SPEAKER_01: I might have, you know, a few lines that might repeat, and that's okay because of the scale of the application.
• 7:44
  SPEAKER_01: As the application grows, I might start applying those principles and patterns.
• 7:50
  SPEAKER_01: So don't look at design patterns or principles as this you must do this to have a good application.
• 7:58
  SPEAKER_01: Again, if your application runs, you've got a good application.
• 8:03
  SPEAKER_01: Can it be better?
• 8:04
  SPEAKER_01: Sure.
• 8:05
  SPEAKER_01: That does not always mean applying a principle or pattern.
• 8:10
  SPEAKER_01: Okay, so that's where we get into the gang of four now, where the gang of four is very prescriptive and it says, here's how to fix a specific situation.
• 8:21
  SPEAKER_01: Okay, it's not going to be this overarching, it applies to everything like solid does or like dry does.
• 8:29
  SPEAKER_01: This is very specific to a specific point in time, a specific piece of your application, you might apply a pattern.
• 8:42
  SPEAKER_01: So here's what you don't want to do.
• 8:45
  SPEAKER_01: You don't want to say, I need to learn the game of four patterns.
• 8:48
  SPEAKER_01: There's, I think, 23 of them.
• 8:51
  SPEAKER_01: Don't learn those and then say, okay, how can I apply those to my application?
• 8:56
  SPEAKER_01: That's kind of backwards.
• 8:57
  SPEAKER_01: What you want to do is when you're building your application, if you see a pain point, if you see something where you say, I was kind of having some friction here.
• 9:09
  SPEAKER_01: Maybe I'm having too much repetition, or maybe it's too tightly coupled, or something like that.
• 9:15
  SPEAKER_01: Then you can look and see, hey, is there a pattern that can make my life easier in this situation?
• 9:22
  SPEAKER_01: But notice you had the problem first, then you came up with a solution using a pattern.
• 9:30
  SPEAKER_01: And that's where I'd like to see you apply these patterns.
• 9:35
  SPEAKER_01: Is I want to see you look at your problem, identify your problem, and then go see if you can find a solution in the patterns or principles.
• 9:46
  SPEAKER_01: That's a much better way of going about it.
• 9:48
  SPEAKER_01: Otherwise, you're gonna write a ton of code, and really some of it's gonna be bad code.
• 9:53
  SPEAKER_01: In fact, when I look through the Genga 4, there's a lot I almost don't want to teach, and I've really hesitated to teach the Genga Four.
• 10:00
  SPEAKER_01: Because what I don't want to do is come across as saying, use this all the time.
• 10:08
  SPEAKER_01: Okay, because that's more dangerous than you not using it at all.
• 10:13
  SPEAKER_01: There's some patterns where it's really an anti-pattern, it's something you should not do unless you are in a specific, very specific situation.
• 10:24
  SPEAKER_01: So you've got to be careful how you use patterns.
• 10:27
  SPEAKER_01: Don't approach it as in order to be a better developer, I need to apply these patterns.
• 10:34
  SPEAKER_01: Approach it as I have a problem in my code.
• 10:38
  SPEAKER_01: Let's see if I can solve that with a pattern.
• 10:41
  SPEAKER_01: Let's see if a pattern makes my code better in some way.
• 10:44
  SPEAKER_01: Now it is helpful to know these patterns so you have a better frame of reference to say, oh, you know what?
• 10:50
  SPEAKER_01: I could probably solve my problem here by applying this principle or this pattern.
• 10:57
  SPEAKER_01: Okay, but don't go looking for how to apply it.
• 11:02
  SPEAKER_01: Look for your at your code at the problems and look to solve them.
• 11:06
  SPEAKER_01: Okay, so that's my thoughts on design patterns.
• 11:09
  SPEAKER_01: They are great.
• 11:11
  SPEAKER_01: Design principles are great.
• 11:13
  SPEAKER_01: Just be very careful that when you're applying them, that you're doing so to solve a problem, not just to theoretically make your code better.
• 11:24
  SPEAKER_01: More complex code isn't better.
• 11:28
  SPEAKER_01: What you want is simple code that runs well.
• 11:32
  SPEAKER_01: If you have a problem with your code where it may be simple but not running well or not not functioning the way you need it to, that's when you might be able to improve it with your pattern or principle.
• 11:44
  SPEAKER_01: Okay, so that's that's my thoughts on this.
• 11:46
  SPEAKER_01: That's why I haven't really gone into Gang of Four yet to teach it.
• 11:50
  SPEAKER_01: I will at some point when I get some time, but um I want to be very careful about how I do that in order to not lead you down a path that's actually gonna hurt you rather than help you.
• 12:02
  SPEAKER_01: Okay, so that's it for this video.
• 12:05
  SPEAKER_01: If you have other questions about design patterns or just questions in general, leave them down below in the comments.
• 12:12
  SPEAKER_01: I will definitely get back to you and answer you as soon as I can.
• 12:16
  SPEAKER_01: And if it's a great question that I think we can all benefit from, I'm going to put it on the list and hopefully address it in a future video.
• 12:24
  SPEAKER_01: Okay?
• 12:24
  SPEAKER_01: Also, leave a thumbs up if you like this video, share it.
• 12:27
  SPEAKER_01: I really appreciate that.
• 12:29
  SPEAKER_01: Okay?
• 12:29
  SPEAKER_01: Thanks for watching.
• 12:30
  SPEAKER_01: And as always, I am Tim Corey.
• 12:32
  SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
• 12:35
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 12:39
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions.
• 12:46
  SPEAKER_00: You can also send your questions to questions at IamTimcore.com.
• 12:51
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 12:58
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.