197 What Is the Purpose of Design Patterns?

Why do we have design patterns? What is the purpose for having design patterns? If design patterns are the way to go, why don't we always use them? Are there times when design patterns should be ignored? These are the questions we will cover in this episode of Dev Questions. 

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:25

What is the purpose of design patterns? Why do we have design patterns and why are they important? Now, normally when you see a question answered on dev questions, it's from a user. It's from my suggestion site or someone else asking me. This question is more an amalgamation of kind of bad information about design patterns that have been kind of given to me from developers. So I want to talk through what's the purpose of design patterns because I think it's important to understand why they're there, how to use them, and how not to use them. So let's start with the fact that most new developers seem to get this wrong. In fact, if you have a degree in software development, you're more likely to get this wrong. In school, you were taught design patterns. Whether you go through a few basic ones or a whole group like the gang of four, you're taught that knowing how to use these patterns is really important. And that's true. But it's also misleading and sometimes dangerous. So let's start at the beginning. What are design patterns? Design patterns are a general guide on how to solve a common problem with a common solution. Simple. So in software development, we come across common issues. Most applications usually end up with a few common things in common. And so since they have things in common, we figured out ways to solve them in a way that makes sense, right? So it's a general guide on how to solve a problem with a common solution. So that's what a design pattern is. So what's the goal of a design pattern? Okay? That's important to understand. Not just what it does, but what's the purpose? What's the goal of a design pattern? Well, the goal of a design pattern, quite simply, is to make our code better. So how does it make our code better? Well, it may make it easier to maintain, easier to understand, or easier to extend. So design patterns are designed to make something better about our code. It yes, allows us to solve something in a uniform or similar way over, you know, multiple times, kind of don't repeat ourselves. But the goal of a design pattern is to make it easier in some way for our code. So in general, design patterns, though, add complexity to our code. When you add a system, that adds complexity. So complexity can make code harder to read. It can spread out where the code is, and it can make the code harder to maintain. Instead of just having all the code in the program.cs file, now you have it in four different locations. That's harder to maintain. It's spread out, it's in more spots. When you change it in one place, you have to think through how does this affect other places. That's the trade-off of using design patterns. So if the pattern doesn't make the code better, then it's not worth using. You see, it's not free. Design patterns aren't free. They have a cost, a cost of complexity. And so if we use them for no purpose, then we actually make things worse, not better. Here's an example. When I walk to the mailbox, I just slip on my slides and go. It doesn't really matter if it's sunny or if it's windy or if it's even a little misty. It doesn't really matter. I just slip on my slides and I go. I usually am barefoot in the house. So that's all I do. Okay. But if I'm going on a hike, I make sure that I have good socks, the right shoes or boots, and that I'm dressed for the weather. Okay, do you see the difference? So I'm applying a pattern to my behavior in a second example. That pattern is here's the things I do based upon the problem I'm facing. The problem I'm facing is I will be on a hike. Therefore, the solution is to apply a con pattern of putting on better socks and making sure I have the right uh hiking boots or shoes, making sure that I'm you know accounting for the weather, whether it's sunny or whether it's cold, whether it's windy or rainy. I've added complexity and startup time in exchange for the long-term benefits. Now, when I'm going to the mailbox, I don't need that complexity. Imagine if I want to walk to the mailbox and I say, okay, I need to change the pants I'm wearing. I need to put on the right shirt. I need to go check the weather and figure out what it's gonna be like so I can know if I wear a rain jacket or not. I'm gonna change my shirt so it's the you know right athletic shirt and don't I can get dirty. I'm going to put on the right hat and then you know get some, get my socks out of the bin, the the actual hiking socks rather than just the you know athletic socks that I have. I'm gonna get the right boots out, I'm gonna lace them up all together to the mailbox. I don't need to take all that time and add all that complexity when I'm just walking in the mailbox. So what if it's a little windy? So what if it's a little bit misty, or so what if it's a little sunny? It doesn't really matter because I'm only gonna do it for a short amount of time. It does not have a great impact in me going to the mailbox and back. And that illustrates why I recommend new developers build software before learning design patterns. You can spend a lot of time doing research on exactly what to wear on a hike. And you know what, you could figure out exactly what to wear and how to dress and how to evaluate the weather and so many other things, but if you go on hikes a lot, you're gonna figure out what works best for the various situations for you. And you might find, okay, I I like this sunscreen, or I like this hat, or I don't like this hat. You can try different things out and figure out what works for you. You could you know learn a lot of head knowledge and quiz yourself on the types of hikes that require what types of gear, but having the actual experience of hiking, you'll know what complexities are worth it for a given situation. And then you can learn about the actual things that people say make life better, because then you can figure out does that really apply to me and how I do things? So you're learning the design patterns just later. You're applying them later when you figure out are they necessary? So design patterns are the same way. Learning the theory of them can actually cause problems. If you're experienced in a design pattern but not on how to build applications, you're tempted to apply patterns to every situation. The danger there is you might not understand there could be a simpler way because you've never done it differently. By practicing development first and learning how to build applications, you'll learn what areas of complexity could be simplified or improved with a pattern. In fact, you'll probably create your own solutions that turn out to be very similar to existing patterns. And at that point, learning the design pattern will further improve your skills without endangering your application. So, in general, design patterns are there to reduce complexity in our code. That means they have to remove more complexity than they add in order for them to be valuable. Otherwise, you end up trying to apply domain-driven design and clean architecture to a microservice and wondering why it's hard to maintain. I have a video on YouTube that talks about building the perfect console application. And we spend a lot of time, put lots of really good things in the console application, and at the end of the day, it prints out hello world when we could have applied none of those patterns and just wrote console.write line hello world. Now, that doesn't have dependency injection, it doesn't have logging, it doesn't have error checking, it doesn't have all these things. But does it need it? Or is it just wearing slides to the mailbox and back? You see the difference? So that's why I say that design patterns, the purpose of them needs to be to make your code better. And if you don't know how the stated code before design patterns, you won't know if you're being successful or not. That's why I want developers to learn to build code first and learn how to build applications and learn to understand the bigger picture and then start figuring out how to apply design patterns in a way that makes them even better as developers. Because often in jobs, you only have the opportunity. You may be using design patterns, but what your job is is just to maintain the systems or fix bugs or other things that work within the system. But as you grow in your skills and you've seen things, and you see how applications work and you've seen the pain points, then you can start to figure out how to fix the pain points. Otherwise, what you have is a whole bunch of band-aids you're applying all over yourself, not realizing you don't have to apply that until you're bleeding. Okay, that's my thoughts on microservices, why they exist, and how to use them well. Thanks for listening. As always, I am Tim Corey.

SPEAKER_01 10:35

Thank you for joining us for this episode of Def Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamTimcorey.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.