Leveraging Your Language, Leveraging the Environment

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 where we're looking at practical object-oriented programming. We're getting to the final stages of the season. In this episode, I want to look at, we'll call it leveraging your language, leveraging the environment that you already have. We started out way back, episode one, talking about how frameworks and languages have really made object-oriented sort of the common approach in a lot of places and a lot of development. There is an underlying object-oriented programming theme that goes on. There are, in most languages, a lot of them are at least object-based, if not fully object-oriented. We have started to think, for the most part, in an object-oriented way. With that, we have had languages support that. Languages have tried to build on that. Some are object-oriented languages, and that is the natural progression of them, like a C sharp or a Java or things like that. Python and all of these have these, but there's different layers of object-orientedness within the language. I think one of the things that we miss out on, partially because languages are continuing to evolve, is that we miss out on features that are built in that actually make our object-orientedness more likely and easier to do. These are sometimes very simple things, like, for example, iterators. We have always had to loop. That's just what code does. It's somewhere along the way you have to loop. You have to do something multiple times across a set of values. That's basically what an iterator does. That pattern says, give me a set of this thing, and I'm going to perform this action across everything in the set. Maybe just walk through it, and maybe it's more complicated, and maybe I can pass a method in and it's going to just execute that method across each of those. Actually, in most cases, we have a brute force approach that we can do. We can throw our collection into an array of those objects, and then walk through the array and have an index value and walk through them. Sometimes we've got something more elegant, which is what I want to focus on this time, is the idea of there being more elegant solutions to some of our problems. Even though those elegant solutions, maybe we'll put that in quotes, are less code and they may not be as fast, they lead us to simplify our solution. They lead us down paths that are going to keep us from reinventing the wheel. Most of them do go back to the idea of patterns. If you go back to, we had a whole season on that, but if you look at the patterns of object-oriented design, things like an iterator and factories and flyweights and MVC and so many different patterns that are out there, these will help us and these language constructs will help us to more quickly and efficiently design our system out. When we look at some of the features of a language, it is worth it for us to review that on a regular basis. Take a look at your code, particularly if a major version comes out, a new version of a language comes out and you're converting maybe or porting from version five to version six of whatever your application and language are. Take a look at new features, particularly, because they're always going to be highlighted. That's going to be one of the big things that you're going to see. Bug fixes are usually some sort of an addendum and a whole bunch of stuff that's really tedious to walk through. New features is usually going to be top of the page and they're going to start with a very general idea of, hey, this new feature does this thing. This is how it's good and helpful and cool and makes your breath smell better and your teeth whiter or whatever it is. Then they will usually have examples and maybe tutorials or links on how to best use this new feature. In so doing, particularly when you're newer as a developer, I think you'll find that you will come across concepts or approaches to problem solving that you haven't seen before. like software patterns in general, these have grown out of other developers having to solve the same or similar problems over and over and over again. They find ways, usually they start out by saying it would be nice if the language did this. Then at some point, the language does that. They add that support into it. Now something that maybe took you dozens or hundreds or thousands of lines of code to do is a simple function. Maybe it's just a call or maybe it's just some sort of a language construct that you can use. These are usually going to be very powerful in extending your ability to object orientize, if that's a word, your solution, your application. Some of the things I think it would be things like templates. You have the idea of template classes, I think exists in a couple different languages and I forget what they're called in each case. Java definitely embraces them. What these things do is a lot, I over simplify this, but basically it allows you to in a way genericize a solution, but also still having some level of type checking or something along those lines. It goes back to the idea, really we have in a lot of these, of having base classes or interfaces that as long as that method is implemented by a class, then we can do stuff with it. These become very valuable when we're wanting to use a collection and we're trying to do stuff across a collection of objects that are maybe very different, but we know that we want to do the same function to them. Common kind of thing with this would be either like a save or a load or print. Print a console, print a file, just run through a bunch of objects and whatever print means to that class, to that instance, do it, perform that. This could include initialize things, kinds of steps. It can include creation and destruction and de-initializing. Depending on how you do it, it could be things like releasing resources or the idea of essentially garbage collection or something like that. a broad range of stuff that we do that languages will eventually support. Early on, like everything else, version 1.0, there is a core set of functionality that's maybe a minimally viable product, but something along the, it's definitely not going to be the maximum viable product. There's always going to be new features. Languages do this, particularly in point release, or not point, but like full version releases. Version 2 to version 3, version 3 to version 4. Languages plus environments. If you have a big step up in SharePoint or NetSuite or PeopleSoft or Salesforce or something like that, these things, when they have major releases, then typically you're going to see a lot of new features. One of the problems that we run into, I think, particularly maintaining software, is that things that needed to be done a certain way in version 1 or version 2, when we move up to version 3 and version 4, and now we have maybe a more elegant or just an easier to maintain way to do that, we don't go back and fix those problems. This is, in a sense, it's the, I don't know, the dual-edged sword that when you move to a new language, to some extent, you automatically will have technical debt to deal with. Because there's whatever you did in the prior version, however you approached that solution, there now is possibly and probably an opportunity to do it better. And it may be just in general, so it's easier to read or easier to maintain. It may be that the language itself has made some adjustments, and those are sometimes the trickiest ones. The ones that are most important to take a look at, new features, big changes, things like that. And it can be substantial. It could be something where a language, and I don't know if this has happened, but it could be a language where they have a collection type of a set. They just call it a set. And that's what they've had all along. Well then, say in a version, now they have a tree, which is a different form of set. And now they've introduced a tree because there are certain set methods and functions that they want to tune, essentially so that now in certain situations, you want to use that tree instead of a set for some of the activities you're going to do on it. Well that can be, sometimes it can be actually a very substantial amount of coding. But along the way, as you're going through versions, it is something that you need to be aware of. And if nothing else, when you're doing essentially new development, do it the right way, the new or the approved or the best practice way. And you can always tag a little to-do comment into your older code that says, hey, this isn't a legacy approach. At some point, if we touch this, we probably should rewrite it in the new or proper way. So keep an eye out for where your language, your environment will help your design process. And this is something, it's a step that I think we don't always take necessarily in the right order or anything like that. But theoretically, there should be a step of you design your solution. And then there should be a step where you take that design and you essentially do the design within the language or the framework that you're going to use. It's a detailed design. It's not implementation necessarily, although it may have implementation hints. Really what you're doing is you're saying, I have this generic, this general design for my solution and it can be object-oriented. You can talk about data items and actions that need to be performed on them and attributes and things like that. But then when you step into a particular language and implementation environment, there are going to be adjustments probably that you're going to make to that design. And they may just be refinements. Maybe where you very generically described how a method works in your overall design, when you get into the more detailed design, you can say, hey, this is an opportunity for us to take advantage of X feature that is supplied by the language, which of course does mean you have to understand the language. So even though, yes, you can take your object-oriented design skills to any object-oriented environment, there is a benefit definitely of understanding how that environment supports the kind of design that you're looking at. And sometimes it may not. That is sometimes going to be the issue. So you do need to think about the environment you're in and how it can help and maybe sometimes limit your design. Challenge of the week? I'm going to keep this one simple. Think about the environment you're in and just some of the problems that you work with. Is it limiting? Do you find that there's maybe one or two or many places where you are limited by the solution you're using, the technology you're using? Or is it on the other side where you can see a lot of places where it benefits you and makes it a lot easier to solve the problem you're solving? And maybe it's a mix between the two. But if it's very heavily you fight against the environment, maybe that's an opportunity for you to look for a better technology, a better framework for your solution. Because definitely there are situations where there are environments that we have available to us that are not well suited to solve certain problems. And some that are ideally suited to solve certain problems. So it's good to find that best fit. That being said, I hope you are the best fit for your day ahead and you go out there and have yourself a great day, a great week, and 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. One more thing before you go. Developer Noir podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, it'd be great if you go out to developernoir.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.