Data Hiding and 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're continuing our season where we're looking at object-oriented programming and practical applications of it. This episode, we're going to look a little bit more into essentially data hiding and encapsulation, and we're going to use this episode to really focus on more the practical side as opposed to the theoretical side. Now, the first part of the practical side is don't, it's sort of a law or rule or maybe just a nice recommendation. Do not expose things that do not need to be exposed. Now, one of the habits I think that most of us get is we'll create an object and we'll have some properties or attributes. And the first thing we do is create a bunch of getters and setters. And there are tools that do this for us anyways. It's real easy to, and a lot of tools, create your object, define your properties, and then there's some sort of a menu option or something like that that's essentially create getters and setters for all of those attributes. That's not really a good thing to do. And the reason why is because you may never use some of those getters and some of those setters. Now, the getters are, you know, you're just going to get values out. Okay, you know, maybe you don't think you're ever going to need it. However, if you don't ever retrieve it, that's sort of a hint that maybe you don't necessarily need it. Maybe it doesn't need to be a public attribute. And really the thought there is that the less you expose from the start, the less you have to refactor somewhere down the road. So, for example, if you have, and this is a great example I think I see a lot, if you have an object that in the database, you know, in the back end where you store it, you have, we'll call it auditing information, you know, such as when was it created, who updated it last, when was that last update date, and maybe what did they change? That kind of stuff can change over time. You may initially say, I just, all I care about is whether somebody, who was the last person that changed it? Or maybe initially all I care about is when was it last updated? But then somewhere down the line, there's maybe a request for who updated it last, things like that. Things evolve. The key here is that if you initially have a get for who modified it and the date and things like that, then you've sort of locked yourself into being, having to at least provide that. Whereas you could otherwise, you know, somewhere down the road, completely change your auditing. And if you don't have any gets to it, then it doesn't really, it impacts nothing as far as the usable code. And this is really one of those cases where it shouldn't. The auditing stuff should be rare for the most part. And so, or at least the usage of it, it's really there for a history as opposed to something that's, you know, probably part of your general usage of that data. So why expose it and put yourself in a situation where you have to refactor some things when you really have no need to do so? It's just making extra work for yourself. So you can start out storing a user ID and you don't have to have to at any point resolve that ID out to a user record. At least initially. And so why do it? Why bother pulling all that extra code in or doing that extra effort when there's no need to do so, particularly when you're going to end up in a situation where you might have to refactor at some point? It's one of those things that maybe initially all you care about is who did it for an audit purpose. Maybe there's a report that you pull at some point that does something, maybe shows like by department or by username or something like that. That's fine. When you get to that point, build that report, but don't bother doing it within the object itself. And actually, the audit information itself may not need to be in that object at all. That may be something that you just basically tack on when you do the save or the update to the database. You don't need to know for that matter. You may not even need to know what your ID is. It may not be a big deal. And by ID, I mean like your primary key, if it's just a number. Now, if it's meaningful for a person, it would be maybe email address or Social Security number, maybe an account number for a customer or something like that. Yes, you probably are going to need that to some extent because you need to be able to tie the data back to the database. But other than that, the actual data ID you may not need, which we see in some of the things like Django. When we've looked at that, some of our tutorials on that is the model system that it has by default. So there is a back end ID, but you don't actually see it in the model itself in the instance of that data within the application. So don't do it as you go, as you need getters and setters. Then create those. But you may have stuff, again, from the setters. There may be stuff internally. Maybe there's some calculated values or something that's grabbed essentially behind the scenes and is data that needs to be a part of that object in the store version of it, in the database or whatever that backing store is. But it really doesn't need to be exposed to the front end. And there's, I think you probably think of a lot of things like that where there's, we'll call it administrative kinds of data that would be part of an object that users really don't need. So why put a get on that? Or for that matter, why a set? Because then once you do, you're locking yourself to a data type and things of that nature. And you're building code that you may not use or may not need. So when you're hiding, don't expose more than you need to. Keep it sort of like a top secret stuff or whatever where something's on a need to know basis. That is the general thought that you should have when you're building out objects. Don't just go in there and just crank out a whole bunch of stuff because that's the standard template. And honestly, that's a problem I have with some of the frameworks and tools that are out there is that they build all this extra stuff and really sort of defeat the purpose of object oriented programming. And one of the goals is to reuse code and to minimize code. If you're cranking out all of this extra stuff, all these extra features or functions or methods or however you want to look at it. If you're cranking all that stuff out by default, then you're bloating your object when you don't need to. So keep it simple. In a similar fashion, when you are dealing with data hiding and really on the get side of this, when you're actually viewing data, it is a good rule of thumb to keep it either as simple as well. Well, actually, it's really to keep it as simple as possible as far as what you send back. Now, this is where objects become they serve themselves as well. So it may be with a return value or when you do a get, what you are returning back is something like a native type, a natural type to the language, like an integer or a string or a float of some sort or boolean. If you need something more complex, then create another object, return an object that should be really by default the way you would want to work so that you can actually grow what you're sending back at some point. A good example would be a general response object to a, like say an API. Because instead of sending some stuff and having to parse through it and things like that, you could send something that says like a return code, a return string, maybe return value where the value itself is an object that could be any object. It could be an integer, could be a string, could be some complex customer record and things like that. When you genericize the results via an object, that's going to help you immensely in the long run. And then also when you simplify, that just means that, yes, you're probably going to end up pushing more work into the back end. But that's okay because that means that whoever uses your code won't have to change stuff if you change things. This goes back, you know, like a date or phone number or something like that, or actually another good example, an address record. I don't know how many times I've been in an application where it's been built, version one goes out, maybe version two. And initially they don't care about a country code because it's all within, everybody's within a single country. But somewhere down the line, somebody from another country comes into the system as a customer, as a user, whatever it is. And now they have to add a country code. Well, if you're sending back an address object, then all you have to do is create that country code on the object. And then you're just passing it around. Yes, you're passing around a little bit extra data in some cases. But if somebody's, you know, some consumer application or class is smart enough to look for or cares about the country, then it'll be there for it. And if not, then it's just some extra data that you're passing around. So you wouldn't want to necessarily build that from the scratch because you don't want to send all that extra data around if you're not using it. However, you do want to have that option. Leave yourselves options wherever possible and try to avoid painting yourself into a corner. So very simple approach this time. A couple of things, you know, points to take out of this one. Keep it simple. Try to go to native return values where possible. If you need to return something more complex, do it in an object. You don't send back some complex string or something like that. And the object itself should be designed in a way that you can easily extend it. It's a sort of a bootstrap method, but it allows you to do some really complex stuff in the long run without having to get real complex early on. And you can even stub some of this stuff out if you needed to. You could have, for example, the address. Initially, you may have like a to string that generates that address as address city state zip. And that's it. Well, then maybe you come back later and it does address a state step. Country. You can just change that formatting a little bit and you're off and running. So keep it simple. And the other thing is, is don't do it on a need to know basis. You know, it's sort of like that. I don't know what do they call it that? Don't ask, don't tell. It's like if they don't ask for the data, don't don't bother providing them a method to get the data. Make it something that as the usage comes out, that's where you start seeing that it's actually needed. Because then at that point, you know, the rubber hits the road and you have to lock down data types and things like that. So think about the usage before you go nuts building out a big framework that may never be used. It's always easier, almost always easier to add than it is to change or to remove. If you remove, then you can have all kinds of problems. So usually once it's in there, it's it's much more difficult to remove it than it is to come somewhere down the line and say, oh, we've got to add it. So challenge of the week for this time is take a look at what are your common classes? What are some of your habits? You know, when you create a new class, maybe do you go out and create getters and setters everywhere? Do you spend a lot of time? Maybe you build a lot of crud stuff that you don't need. Maybe you go in and you build an object, then you right away build some sort of a data, you know, mapper that maps all those values into something for a table somewhere. And then, you know, you do your create, insert, update, delete, all that kind of stuff. And then how often do you actually use all of that stuff that you just created? I'll do it for this time. So 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 today 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 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. 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.