Data Encapsulation in 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 are continuing and actually really starting in earnest our season on object-oriented programming principles and practicalities, as we will call it. In this episode, we're going to dive right in and we're going to talk about data encapsulation. This is one of the primary attributes of object-oriented programming. It's also sometimes used, referred to as data hiding. I want to talk about the practicality of this, and in particular with some of the common traits that exist. We see this today in a lot of frameworks. There's a concept of getters and setters. We have an object, and just because we've started down this path, let's say it's a customer object. They have these traits, and we'll keep it simple. Let's say first name, last name, phone number, email. If you were going to interact with that customer object in the object-oriented programming world with most systems, then you would have, instead of doing, let's say, customer.email, you would say customer.setemail or customer.getemail. You would set an email, you would send a parameter, your email address, and it would set it, or you would get it. You wouldn't have to send a parameter, you would just say get email, and it would return an email address. It's going to be ... We're not going to worry too much about data types, but it could be a string, it could be an object in itself. Maybe that email is an object of some sort that you ... Maybe it has a domain, and then an address, and parameters, or something like that. Ways that we can model this stuff. The key to data hiding is that we can change our representation behind the scenes and still not impact people that use it. For example, if I do want to convert initially, let's say ... A phone number is probably a little easier to deal with because it has those three sections already. It has whatever it's called, the prefix, the main, and the suffix, or whatever it is. You've got your first three digits, your second set of three digits, and then your last four digits. I guess it's what it's area code, prefix, main, whatever it is. That may or may not matter. It may or may not matter that it's numbers. You can initially set up something that get phone number would be ... It's going to return a string, which is the ... Let's say it's a formatted phone number. It's XXX dash XXX dash XXXX, where X is some number. Now, behind the scenes, initially, it may be that you just store that number, but probably not. For example, there are different formats. It may be with dashes. It may be with dots. Dates have the same thing. They may be slashes. They may be dashes. They may be dots. Year first month date, or maybe month day year. There's all this sort of stuff that is really the same thing. Phone number is a little simpler. It may be that there's parentheses around the first three digits, and then a space, and then three digits, and then a hyphen. Think about it. There's different formats that we see. We need to, behind the scenes, we want to be consistent in how we store that, and how we work with it. Maybe we want to save space. Maybe we store it as just, we take out all the non-numerics. It's just 10 digits, and that's how we store it. Or maybe not. Maybe we store it in a different way. Maybe we store it in the three, maybe we store it as area code, and then separately as the number because we want to do searches on area codes or something like that. I'm trying to get you to think through that these things can be more complicated than they initially look. But on the user of the customer, we want them to not have to constantly change how they deal with the phone number. When we create the customer and we say, get phone number, they're going to get a phone number in a certain way. Let's just say we send them that three digits dash three digits dash four digits. Now behind the scenes, initially we keep it as a string, but maybe as the application grows we realize that, oh, we really need to, for space purposes, store it as just the numbers. And so now, where initially maybe we just passed through the phone number, now we take those digits and when they call get phone number, it actually formats it. It goes in and puts the places the hyphens in where it needs to be, and then returns it to the user. Or maybe it pulls the phone number from two different places. Maybe it pulls the area code and then it pulls the phone number and then it puts those together. And maybe we want to have get phone number, but we also want to have one that's like get pretty phone number that slaps the parentheses around it. At some point we say, oh wait, we want to add a country code to it. And maybe we don't send that back. Maybe the email is still going to, or I'm sorry, the get phone number is still area code, but maybe behind the scenes we've got a country code. So depending on where the user is at, where the customer service rep is, then it's going to assume certain country codes and things like that. Behind the scenes things can change dramatically, but that's why we want data hiding. We want to be able to put that facade, that front end in front of the data so we can change implementation behind the scenes. At the end of the day, it doesn't matter. The user sees the same thing. The user of that object sees the same thing. So now we have less code that we have to change when we do major redesigns. The biggest impact we may see of this would be when we have that front end, behind the scenes is actually there's an entire complex relational or non, or object or however it is, or no SQL database. There could be all kinds of complex data relations and calculations that we're constantly changing but on the front end all they ever do is they ask for a number and they get a number back. That's the key is that we can change things in dramatic ways, but we are limited to where we have to make the changes. This goes back to code reuse and things like that. So data hiding allows us to manipulate how we return a result behind the scenes, do extra calculations and things of that nature. Now in the simplest sense, you may think about it, okay, like get first name is always going to be, you know, it's just going to be a first name or get last name is always going to be a last name. But even in those cases, there are things like, well, what happens if their last name is, you know, what happens if you didn't really support hyphenated names? Or what if you didn't have the, like a suffix, like a title or, you know, John Smith the second, the third, the fourth, what if you didn't, you know, where do you put things like titles or, you know, doctor or, you know, if they've got some sort of certification like a CPA or something like that, where does that stuff get organized within your first name last name? And so you want to have maybe rules behind the scenes that fix that. And initially it could be that it's a straight pass through, but down the line you may have to put more complicated thought into it or, you know, more calculations. So while it is, there is a cost in a practical sense to putting those getters and setters because you're creating this function and then there has to be a lookup and things like that. It definitely would be faster to just have a customer object that directly, you just directly can access the name, the first name, the last name, the phone number, the email address. And so, you know, in the object oriented world, we say, you know what, that may not be the case always. So let's protect those. And this is where we have the ability to hide things from the user of the object. And we'll talk about how those things get done in an implementation sense in the next episode. I wanted to get the practical side of why are we doing this? What is it that we're achieving by adding this? In a sense, it's a little bit of a complexity, but it's not because we can rely on patterns in the way we've done it in the past. And that's where we get the standard of get value or set value. Probably most of us are conditioned if we see, if we're working in whatever language and we have something that's an object or a structure, we're probably going to just by default expect that there's a get and a set. Now some cases are a little different. There's things like is, you know, if it's a Boolean where you're going to say is, you know, is X and you're going to expect that it's going to return true or false, you know, there's things like that. But in general, that's still we're hiding data. We're hiding attributes and saying access it this way because I may give you a slightly different answer. And it depends on, it just gets into instances and some other stuff, but there's other things that we can do behind the scenes so that the data hiding at its core, you know, giving us the most simplest approach is it gives us a definition. It gives us a standard language, a way to communicate that we're going to use as understanding that this is what I want you to do for me. Now you may do it in different ways, but at the end of the request, I want you to return this thing. If I ask you what your email address is, there may be a whole lot of different stuff you do behind the scenes, but I'm expecting you're going to give me an email address. So that's data hiding at a theoretical level. So challenge of the day, challenge of the week is, you know, take a look at, just go look for like data hiding or data encapsulation. And you're going to see that there, especially if there's a language that you are currently heavily in, take a look at it with that language and see what it does. There's probably some aspect to it that may be very obvious, maybe something you know, you may be like, duh, I do that all the time. But take a look at it just to see what's there because there may be some things and maybe some coding standards that you haven't been exposed to. That being said, wrap this one up and as always 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 Nord 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 developer.com. Just a step forward today is still progress. So let's keep moving forward together. One more thing before you go, the Developer Nord 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 be great, if you go out to developer.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.