109 How Do I Balance Design Patterns and Code Complexity?

Can we overuse design patterns? How about design principles? Are there certain patterns and principles that we should always use? What is the balance between a simple app and an app that is well architected? These are the questions we are going to answer in today's 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:24

How do I balance code complexity with design patterns? Meaning, how do I figure out where the balance is between a simple application and one that follows well-architected patterns? So, this is the question was asked on the suggestion site, and I thought it'd be a great one to dive into in today's episode of DevQuestions. Now, if you have a suggestion for a future question, go to suggestions.imtimcorey.com, ask it there, and hopefully you'll see your question answered in a future episode of DevQuons. Now, design patterns, let's talk first their definition. It's a strategy to solve a common problem. So there's lots of design patterns out there. So which ones do you use? How many do you use? Can you overuse, kind of like what we talked about the previous week about overusing principles? Can we overuse design patterns? Can we use too many of them? Because there's lots of them. Do we use only three in our application? Five, seven? And a lot of the same principles you talked about last week will apply here. Go check out that episode if you want some of the foundational stuff. But let's talk specifically about design principles. So it's a strategy to solve a common problem. All right? That's what its purpose is. All right. So what we need to do is a cost-benefit analysis. And this is a business term that's been around for a while, our business phrase, but let's talk about this in real-world examples. So I used to live in Pennsylvania. And in Pennsylvania, the winters got a little miserable. I wasn't really a big fan of cold and they got quite cold. And we got a lot of snow as well. So there might be a foot or two of snow outside, and it might be 20 or 15 degrees Fahrenheit for those of you that use Celsius. Sorry, I don't know the conversion for that. But cold, real cold. How about that? Um, so when I was thinking about going to get the mail, which is about 50 feet away from my front door, I might put on a pair of boots and a coat and run out, get the mail, and come back in. Now, if I am going to go out and shovel the driveway, and my driveway took a long time to shovel, it was quite uh large just because of the space it was uh set up for parking cars. Well, I would spend three, four, five hours outside shoveling snow. I would dress differently than going to the mailbox. I would wear gloves, I would wear multiple layers of pants, I would wear a sweatshirt and a coat, I would make sure I had a hoodie on so I could put something over my hand, my head as well as my head needs a lot of protection, um, a hat as well, and I would really bundle up well to go outside. I might even wear a scarf. Why didn't I do that to go to the mailbox? It's the same temperature outside, there's the same amount of snow outside, but yet I dress differently for being out there for five hours versus just going the 50 feet and back. Well, the reason why is because I did a cost-benefit analysis. Yes, I was going to get a little chilly with going to the mailbox, but I wasn't gonna be out there very long. And so it didn't make sense for me to find an extra pair, an extra layer to put it on for my pants and put extra socks on and get my hat on and my hoodie on and an extra coat on and get everything zipped up. It would, it takes me 10 minutes to get ready to go outside when I'm layering up like that. But when I run to the mailbox, I don't even lace my shoes. I just stick my laces in my boots and wear them on untied because I'm doing something really quick, no big deal. I sometimes don't even wear a coat. It's yes, it's cold out there, but I'm not gonna be out there that long. I did a cost-benefit analysis and found that it's just not worth tracking down all that stuff, layering all up, spending all that time when I'm not gonna get that cold because the duration is so short. As opposed to when I'm gonna go shovel, yes, I need all that because that 10 minutes of layering up will save me from getting frozen when I go out there to shovel for hours. So that's the that's what a cost-benefit analysis is, where you say, is the pain or the time or the energy or the effort is that worth the the reward from doing so. That's all I'm doing. So when it comes to writing code, you should think through that same cost benefit analysis. So let's just say you're thinking about implementing a design pattern. Whatever that pattern might be. Well, if you are using a microservice or building a microservice, that might be 50 lines of code or 100 lines of code at max. Well, that's not a lot of code. Maybe you don't need to have a principle or a pattern there, or three patterns or five patterns. Maybe you just need to just write the code. Whereas if you're writing a monolith, which might be a massive application with hundreds of thousands of lines of code, yeah, you need to use some patterns to help manage that and help solve common problems. Because those problems are big, they're magnified when you have a million lines of code as opposed to a hundred lines of code. So there's that benefit of saying it doesn't really benefit us to do this pattern because it doesn't give us a whole lot. Okay. So that's the idea of you know, how do you set this up? Another example might be when you're building a microservice, we might only have one project. Okay, so you'll have one project that's just the code for your microservice. In fact, an Azure function app is a great example of a microservice where it's one file in one project in one application. That's all it is. It's one method, really. I mean, there's a few supporting things to get started, but it's one method. Now you can add more, you can add a class library, you can add um dependency injection, you can add all this other stuff around it, but really do you need that? In most cases, probably not. Now, in some cases, you might. But in most cases, you just need that one method because it's doing something simple. But if you have this massive million-line project, maybe it's broken up into a hundred projects. Maybe you have a hundred different project files on your solution. This is a very common thing in larger businesses to have these massive sets of projects where you're not just opening up one project to two projects inside your solution, you're opening up a hundred or two hundred or eight hundred. And that seems overwhelming, but when you're talking about the size of the application, it might make sense. So you need to think through what's the benefit here versus the cost. So when thinking through patterns, we should think through does it make my application better, easier to understand, easier to maintain? Okay, does it make my life better or does it not? And then do you have a problem or do you have a solution in need of a problem? Okay, I hear a lot of people who are learning design patterns, which is a pretty common thing to learn in school, they learn these design patterns and say, okay, where can I use this? How do I use this? Show me using this. I want to use this. And that can be great, but it might not be the right approach. Because then what you do is you say, okay, I've got this cool tool, I want to start using it. Instead of saying, I have a problem, is there a tool that can help me? That's the difference. So when you approach learning software development as I've learned all these design patterns, then what you start doing is saying, I have all these tools, let's use them. And you end up introducing complexity, making things worse instead of better, because you've got a solution or a set of solutions, and you're in search of problems for them to solve. And so you say, oh, that pattern applies here, that pattern applies here. It might. And that can work, but is it right for your application? Okay, take a step back. Does it make my life easier? Does it make my code better? Does it make it easier to maintain? Because if it doesn't do these things, then yes, it can fit there. That doesn't mean you should use it there. Okay. This is the reason why I haven't taught design patterns per se in the C sharp master course. Because that's really, in my opinion, not the time to learn them. The time to learn them is after you have mastered working with C sharp. Because then you can say, okay, I've learned how to build applications. I've built multiple applications, and I'm starting to see some pain. I'm starting to see some common things that I'm I'm running into where I'm going, ooh, this is this is hard to work with. This is complex. And then you learn design patterns, go, there's a design pattern that makes my life easier here. And you apply it. And all of a sudden, you take your knowledge of C sharp and it becomes better and more rich and full because you go, okay, I know that I've seen this problem, and now I have found a way to make it better, to make my code more efficient, to make my life easier, to just make something that is improves my code's overall quality. Okay. So that's when you should really learn about design patterns, and really when you should start applying them, is after you understand the problems. So you properly apply the solutions where needed. Because sometimes you may look at a code and say, it doesn't have any problems. It's running great, it works great, it's simple, it's easy to understand. I don't need to apply this pattern to make it better. Okay, an example of this is the mediator pattern. This can very easily get blown out of control. Where you might have lots and lots and lots of classes and maybe lots and lots of projects that have broken everything apart into little pieces. But now when you try to see the flow of your application and try and track down a bug, you have to go through 18 different projects and 35 different classes, and things are loosely coupled in a way that's actually hard to maintain. That might not be right for every application. Okay, so maybe you take a step back and go, that's not right for this application. It is right for really big applications or really complex applications where you're making things simpler. But that's a high complexity to start with. Again, remember, if it's a high complexity, you have to have even higher complexity that you're reducing because of what you're adding. Okay. So you may think that through and say, oh, you know what? Yeah, I've learned it and I know it, but I'm not going to just solve every problem with this tool because this tool isn't right for every situation. All right. So those are the things to think through when you are looking at design patterns. Do a cost-benefit analysis. Is the cost worth the benefit? Okay. So if you spent all day working and you got a dollar, well, you're making money, right? Yeah, but is it worth it? Okay. Whereas maybe if you spent an hour working and got $100, you go, yeah, it was worth the struggle because I got paid a lot. So there's that cost-benefit analysis. Do that with your code. Does it make, does the cost of implementing that item, that design pattern, does it is the cost of the add complexity, the added maintenance uh work, is that worth the benefit it gives you in the long run? All right. So that's my answer to the question. I hope that answered your question. If you have a question, go to suggestions.imtimcorey.com, ask your question there, and hopefully you'll see your question answered on a future episode of Dev Questions. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_01 13:35

Thank you for joining us for this episode of Dev 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 IamtimCore.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 IamtimCore.com and enroll in a course.