Practical Object-Oriented Programming

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We're continuing our season when we're talking about practical object-oriented programming. We're going to step back here as we're sort of summarizing some of the key things that we should consider as we move forward. We're going to talk about simplicity or complexity, depending on what your point of view is on this. In general, one of the challenges that we run into in object-oriented design is figuring out the level of complexity or the level of simplicity that we need to embrace as part of our solution. Unfortunately, I think most of us tend to want to go with a more complex, sort of showing off our knowledge kind of solution, which is possible. It can be valid. Essentially what it is is a situation where maybe we embrace every little piece of object-orientedness that's out there. We make sure that we include inheritance and some great polymorphic examples and data abstraction and all that kinds of stuff, which none of it is, as in most things, none of it is bad in itself, but also none of it is good in itself. The key here is when we are thinking through our design is to focus on solving the problem and not necessarily on, let's say, fully utilizing the tool that is available. Think about it from the old construction adages. There was the one thing that if all you have is a hammer, everything is a nail. Well, just because you have a full tool chest does not mean that you need to use every tool. Maybe you've got a hammer, you've got a saw, you've got a drill. If you don't need to cut anything, then you probably don't need the saw. So you don't need to contrive a reason to use the saw. Don't use it. It may not be that obvious and usually isn't when we're dealing with object-oriented design. There may be things that we really don't need. Maybe we do, but maybe we don't. Inheritance maybe is a good example. Because typically, I guess even data abstraction, if you think through these, there are cases where it may not make sense to really utilize that facet of object-oriented. Inheritance. If we've got very simple direct classes that solve the problem, then we may not need to do any inheritance. It may not be that our problem is that complex, or at least the data that we're dealing with or maybe the functions and the methods we're dealing with are not that complex. So we just need a customer object that has maybe a couple of different types, as opposed to a customer base class. And then, I don't know, just picking some random example, then maybe we inherited to have a weekday customer and a weekend customer, a seasonal customer, things like that. We don't really need. We would be essentially creating or maybe even redefining the problem in order to shoehorn in this thing that we want to do. Look at the problem. Look at the solution. And then start into your object-oriented design. Don't use your object-oriented design hat initially from the start, because what you end up doing is you end up pushing the solution into the object-oriented design. With all software development, what we really want to do is we want to avoid that. We want to avoid solving to our platform. Instead, what we want to do is solve the problem and then look at how the solution we have may benefit from the platform we have. Or if we're forced into one, how we make that solution work for our platform. We don't want to make the, we don't want to match it to the platform. We don't want to highlight the platform in our solution. We want the platform to deliver our solution as best possible. And so we may have, things are just not that object-wise that complex. We need to use all of the facets of object-oriented. And even data abstraction or data hiding in some cases is way more than we need. If we're doing a, like a, say a data processing application where we have data coming in, we do some manipulations and we push it back out to some other, some target, some destination. We probably don't need a lot of object-orientedness to it. We almost definitely don't need to worry about data hiding because we don't want to go through that extra step of accessing data. Instead, we need to access it directly because time is of the essence. Speed is important. Every time we put some, we'll call it some barrier essentially to getting data, that's going to take time. And even though that, you know, that barrier may be like a, you know, get value kind of method, there's still, there's time spent doing that. And so every time you do it, you are slowing down your process, which may be, you know, no big deal. The time loss may not matter if you're dealing with, you know, tens or hundreds or even thousands of records. But if you're dealing with millions or tens of millions or hundreds of millions or more, every little bit counts. It adds up. So like everything, you can go, you need to find essentially middle ground necessarily. You don't need to go nuts, you know, in the object-oriented world trying to turn everything into an object and everything has got this really complex interrelation. And you don't have to go the other way where you just say, well, okay, this is just too much, I'm not going to use it. There is value in it. And the good object-oriented designers will figure that out. They find the balance between maintenance, code reuse, scalability, performance, quality, all of those key metrics that we use with our software to determine if it's good or if it's not, if it's valuable or if it's not, or if it falls somewhere in between those. We need to do that with our object-oriented design as well. We need to look at our problem, create a solution, and then essentially we sort of do it again. We examine the solution and look for opportunities to use object-oriented programming. Maybe that's an acronym we want to think about when we're doing object-oriented programming or object-oriented design. Instead of OOP, OOP or OOD, maybe think of more of it as opportunity, opportunity, OO, and then programming. Opportunity, opportunity, design. Look for opportunities to use this approach. And then probably even re-examine that because you want to make sure that it makes sense not only or doesn't make sense, I guess. You want to evaluate it not only with your solution, but with potentially other solutions, other problems that you may come across. As again, we've mentioned before one-offs, things where you're just going to code it once and you're done. You're really not going to ever use that code again, most likely. Then it doesn't make sense to spend a lot of time on the design side of it. The object-oriented, some elegant solution, it's just not worth it. You're going to spend more time putting that together than you need to. And the benefit downstream is essentially zero because if it's one and done, then you're done and you never use it again. If you're building something to migrate data where that data and the to and the from are very unique, you may not want to deal with this at all. You may say, nope, I'm not even going to think about object-oriented. But you should because you don't have to spend too much time in it. You think about it a little bit as far as is this process of moving data from A to B and maybe doing some manipulations, are there some things that I'm doing here that I do know will be useful to do in the future? Now we see this a lot with connections to a system. Yes, maybe I am building this app that I am connecting to whatever back end system and I'm never going to have to deal with it again for this particular problem. But maybe in the future, there's some other application that's going to connect to the system. So the connections maybe are worthwhile to design in an object-oriented way. Maybe the manipulations that I'm doing are code that's going to basically generate code or I'm going to create code to do that that does have use in the future. Those same manipulations may be in just a normal data entry application as opposed to a data migration application that I'm looking at. Maybe they have use there. So again, it comes back to balance and finding that the give and take and the pros and cons of spending some time thinking about your solution from an object-oriented point of view, a reuse point of view, and really balancing that against or measuring that against the performance and the maintenance side of stuff. There is that happy medium basically. It feels like, and particularly in conversations with developers, that sometimes we get too enamored with the technology. We see some feature, something that we can do, and we say, oh, I really want to do that. And so we end up with a solution looking for a problem as opposed to solving a problem. And now sometimes there are some products and some situations out there where it makes sense to take a solution and try to figure out where the problems are that this solution works for. But more often than not, really what happens, we get paid at the end of the day, we get paid. It usually is, and by usually, a vast majority of the time, it is to solve a problem. It is not to create a solution and then go find a problem. If you want to build a product, if you want to build a software company, then maybe you can do that other approach. But most often, we are solving problems. And we need to keep that as our focus. That is our why. That's why we're here. Why we're doing all of this is to be able to solve this problem. And Object-Oriented is going to allow us to solve this problem, its goal, what it offers us is to solve this problem in a way that we can easily maintain it, tweak it, adjust it so our solution can be refined in the future, and also in a way that the work we do in solving this problem can potentially be applied in solving other problems. Code reuse. That's our focus. It's not that we can do some cool inheritance or data abstraction layer or something like that. It comes back to the problem. If you want to be a good software designer, if you want to be a good Object-Oriented designer, it still all goes back to solving a problem. And then the design part is taking the solution and finding the best implementation of that solution. The solution comes first, then design and implementation. And that's all I want to deal with on this episode. I think that's enough to chew on for a while. And so your challenge of the week is, where is the happy medium with the software that you're currently working with? Take a look at what you're writing, what you've designed, or maybe what you are designing. Is it too much or too little in the world of Object-Oriented? And more importantly, are you manipulating the solution for your technology or are you manipulating the technology to provide the proper solution? There's a big difference between those two. And that being said, I hope there is zero difference between you and going out there having a great day and a great week. Because as always, once you do so, we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Noir podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernoir.com. Just a step forward a day is still progress. So let's keep moving forward together. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Noir. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noir site. You can also find it on Amazon, search for Rob Brodhead, or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week. This is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at developernoir.com if you would like more information. Now go out there and have yourself a great one.