Building Better Developers, The Develop-a-Noor Podcast

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've taken a little break, but we are back to it with our latest season. This time we are going to talk about object-oriented programming. We're going to cover some of the basics, but we're also going to get into some practicalities and how we actually utilize these concepts and theories in modern development. This episode, I want to just sort of set the table and talk about it in a general sense to give us an idea of, you know, sort of get us on the same starting point. Now object-oriented programming has been around for now a couple of decades, and it has evolved. And it has become something that, while it was very revolutionary at the time, has become sort of, I don't know, watered down in many ways as we've gotten into modern development tools and frameworks. The original goal, or at least one of the original goals of object-oriented programming was to be able to code stuff essentially one time and then send parameters in and use that code over and over again. The idea of code reuse, of not having to copy and paste your code, or really more specifically, not having to solve the same problem multiple times. This is a natural, I think, growth from functional programming. If you think about the history, or maybe you don't know, but starting out with the history of programming, initially you would write code that would do something, and then you would do something else. You'd come back, you'd do some other things, and it's just a series of commands. And so if you think about it, just a simple kinds of task, this may be through a day you would say, tell somebody, get up, brush your teeth, have some breakfast, go out to the mailbox, do some of your work, exercise, have a meal, brush your teeth. You start seeing that there's going to be some repetitive stuff from day to day, even within the day. So maybe periodically you take a break, or you periodically check your email, things like that. Those tasks, those commands became functions. People realized that we're writing the same code multiple times. So let's find a way to refer to that code. Now way back there was things like there were loops and go-tos and things like that. But functions allowed a more, a cleaner, easier to read way to do that. And the back end under the covers, how computers do it is probably not changed that much. But from our point of view as a programmer, we now, instead of saying go do that again, we can just give it a function name. So if you want to check mail on a regular basis, then you just say check mail. You don't say go to the check mail code or anything like that. So once we got the idea of functions, of units of work, then there is a sort of growth that there are other relationships within solutions that we wanted to make it more applicable from a programming point of view. And that's where we start getting into the idea of object oriented programming is that you have essentially you have objects and you have actions and actors in any, essentially any situation. If you want to drive a car from point A to point B, then you have the car object, and then you have a driver that is an actor within that. And then you have actors doing things with or on objects. So it may be the actor or the driver may start the car. They may engage it. They may accelerate. They may break. They may turn. All of these are things that essentially the actor is communicating to the object, in this case, the car. So through the steering wheel, you're directing the car, essentially turn the car to turn right, to turn left. And we know underneath the covers that they are behind the scenes when we turn that steering wheel, that it's causing other things to occur that end up turning wheels. When we press the brake, then it does things which allow sets in motion, things that will slow down, maybe reduce the engine and put some sort of reverse pressure on the wheels, things like that. That's where object orientedness comes from. Our goal is to essentially encapsulate in a way, and there is a kind of encapsulation has a special term or a special meaning within objornate, but we want to, maybe a better word would be define the environment within our program, our problem environment, our solution environment. So if we want to, for example, create an application that is tracking, it's a customer relationship management kind of thing, very simple. We have customers, we have interactions with them, and we want to be able to track those and report on those. Oh, within those, then we can see, and even in the description I gave, there are objects. We talk about, in this case, a customer. There is somebody doing thing, which would be us, so there's an actor, there is a relationship manager, however you want to look at that, and then there are actions. And so this object oriented programming concept, while helping us reduce code bloat basically, and allows us to reuse problems that we've, code that we've already used, it also allows us to better model real life into the world of software, because we can look at the objects and the actors and the actions in the real world and say, okay, we want to model these in our solution, in our software solution. And we have ways in object oriented programming to make those mappings. So in the example I use, we have the way to create a customer object. And then what's key in the object oriented world, because you can do this in a non-object oriented approach, you can make whatever language or structure you're working with sort of do this, but then we're going to find that there are, I say limits. You end up in a situation where you have to do workarounds instead of the system providing you the tools to more easily model it. And so we start considering the idea of, okay, well, if I have a customer object and I have a, we'll say a CSR, customer service representative object, then there's certain traits or attributes that each of those are going to have. As a CSR, you're going to have traits like, I don't know, maybe like an employee number, an ID, first name, last name, maybe a phone number. Customers are going to have traits like same thing, email address or phone contact information, first and last name, organization they're with, their sales history or order history or contact history, depending on what the relationship is there. Whether they're, maybe whether they're a warm prospect or a cold prospect, whether they have gone through certain relationship gateways, maybe they've signed up for something, maybe they've signed a license, maybe there's certain agreements that they've done, certain steps along the sales process that have been completed with them. And then there's actions. You may have a CSR would maybe contact a customer or a customer contacts a CSR. And you want to be able to group those things with the actors. And this is where the objects become more than just, they're not just a data store. So it's not just the attributes, there is also the actions that one can perform. So a customer can contact a CSR and a CSR maybe can contact a customer, but maybe a customer can't contact another customer. And maybe CSRs can only contact certain customers. And we start putting rules. And so now we want to have a way to group these things. And that is what object oriented programming is going to give us. And so if we want to keep it very simple, we're going to talk about modeling problems in software. That's probably the core of what we're going to cover in this season. And so moving forward, I want you to keep that in mind. And I, as always, I will remind you on a regular basis, but we're going to start with that in mind. We're going to go into the core concepts of formal object oriented programming. We're going to talk about what the programming languages that are out there that support this to varying degrees. And then we're really going to dig in most of the season. We're going to start looking at specifics at certain problems that we see and object oriented solutions. It's going to be similar to patterns. When we talked about software patterns a couple of seasons back and any patterns. But we're going to get a little more, probably a little more specific and not necessarily talk necessarily about patterns, which are generic solutions. We're going to get into some more, I think it'll probably be a little more specific solutions as we go into it. Another thing as we get into this season, I want to try to cut these a little shorter, keep things a little shorter as we're going through so we can keep a little more focus because of the scope of the discussions we're going to have. So these will be a little bit shorter episodes, hopefully a little easier for you to keep up and also to use as reference points later on. Try to keep a little more specific and a little more useful, hopefully to you in the audience. So as always, a challenge of the day would just be to take a look at object oriented, just Google it real quick or something like that and see what's out there. Because there's going to be, like I said, this is sort of faded a little bit. It's not as near and dear to people's hearts, maybe as it was 10 and 20 years ago, because it's just become a part of software development. But it doesn't hurt to refresh your memory a little bit as we stroll down memory lane and look at object oriented programming, but then bring it into the reality of what we're doing on a day to day basis so we can become better programmers, better developers. That being said, hope you go out there as always, 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 Noor 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 developernoor.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 Noor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noor site. You can also find it on Amazon, search for Rob Broadhead, 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, and 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 developernoor.com if you would like more information. Now go out there and have yourself a great one.