Data Hiding 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 our season where we're looking at object-oriented programming. This episode, we are looking at, probably going to do at least one more, wrapping up a little bit, the idea of data hiding. And this is partially practical, partially getting into a little bit of the technical side of it. But I wanted to address the idea of private, protected, public, and we'll call it package-level restrictions that some languages provide. That are, from an object-oriented point of view, most will have private, protected, and public. And I'm going to talk about what these things mean in a general sense. So your language may be a little bit different than what it does. It may not be as clean as far as how it provides these sort of options. And it may be more, there may be some other, I don't know, flavors that are allowed. So generally what happens, public means public. Anybody can access the attribute or the method that you assign to public. If it's private, then only that class, so only a reference, an instance of that class, is going to be able to make a call or make a value change on that attribute or for that method. And protected typically means that you have, and that's what we're going to talk about. This is what we'll use for the definition for this discussion. Protected is an instance of the object or something that inherits from it. If I had a vehicle that had something that was private, only a vehicle instance would be able to modify it. However, if I had a child, let's say truck inherited from vehicle, if it was private, truck wouldn't be able to access it. If it was protected, then truck would be able to because it's a subclass of vehicle. In a similar sense, which is typically what happens, there's also the idea of sometimes a package level protection, which would mean, and this really is useful if you have helpers and things like that. So you could have a, in the vehicle sense, so maybe you have a, let's say you have in that same package, so you've got vehicle related stuff. We'll just call it the vehicle package. So you have a core vehicle object, got truck that inherits from it, and maybe you have a mechanic object out there as well that would be within the same package. So if package level restriction would allow the mechanic to work on something on a truck, for example, whereas protected would only be within the hierarchy. So that's just to set the table a little bit for these, for this discussion. I will fall back on what we talked about in the last episode, as far as private is concerned. Like everything, really with object oriented, it is best to leave everything on a need to know basis. If you by default consider everything to be private, then only move it up to either protected or public as you see a need for it, then that's generally, that's going to be a good rule of thumb. That's generally the best approach to take. And this becomes with properties and attributes, really, there's almost never, I really cannot see any reason to make something public. It should always be accessed through some sort of an accessor, a getter, a setter, or something like that, and maybe not even directly. So there may be under the cover side effects that are done by, performed by a method, which is how that data actually gets manipulated by users or by objects that, instances, I guess, that use that object or that use instances of that object. When you, when you keep it private, this goes back to the idea of you can then change around all sorts of stuff. You can change data types, you can change how it works, how it's modified, how it's calculated values and how they're calculated. And then you've got that public interface that other things can use to access the data that they need or the results that they need. This works with, really this works with methods as well. I think a lot of times the sort of the typical approach that a lot of developers take is that all of the attributes are private and all the methods are public. And I don't think that's, that really doesn't make sense. Well, I don't want to say it doesn't make sense, but I think it is better served if you don't use that particular approach. And that is because I see in a lot of objects I use, even not terribly complex ones, like a, like for example, a customer visit object, sometimes even addresses and things like that. Where there are, addresses is another good one. You know, you think that's pretty straightforward. You've got, or let's say contact information, but even an address, you've got, you know, city, state, zip, country, and really that, I guess like street address, you know, street address kind of stuff. So you would think that, oh, okay, I've got those values, I've got getters and setters, and that's about it. Well, you may have some, essentially some like helper and validation types of methods that would go on to that. So for example, maybe you have instead of like set zip code, maybe you, or maybe you do with an even with like a set zip code or get zip code, both of those under the covers would actually be doing some validation. And you may want to do that in multiple places. So instead of putting the validation directly in the set zip code method, you would have a validate zip code method that you would call as part of the set. And then when something's set, you would either say, yes, you know, maybe you return back to a false success or not, you know, or maybe a result that says it was successful or not. And then there's some sort of a message involved or you can raise an exception. I mean, there's all kinds of things like that. You can do. But the point here is that there are often validation in particular, but other helper in formatting types of methods that make sense at the class level that really should not be exposed to the other objects that could use that. Again, because you're actually, you got to think of it validation and formatting and some of those kinds of things. There's sort of the equivalent of your secret sauce for that object. And if you expose that, then that means that you can't really change it. Yeah, there's, there's going to be a level of expectation, even if under the covers, you're doing a lot of work in that method. The fact that you've exposed it means that from here on out, that method has to have the same signature. It has to take in the same parameters. It has to return the same stuff. And if it has side effects or something like that, then it becomes really difficult for users of that object in the future. So keep your, your interface clean and simple and where you need other things, helpers and validators and things like that. Just go ahead and keep those private so that those are only called within the instance. That way you think of it in a lazy way. That's less that you have to document. That's more that you can call it play around with that you can tweak and make adjustments to without any calling object, caring about it. And when you look at things like testing, that becomes very key because now you don't have to test directly your, your, your method. You instead could have the same test suite, especially regression testing and stuff like that, point it to your, to your application, run it through its paces. And now you don't have to change the test. They're the same ones. They should have the same expectations. And that actually is a bonus to you because you can compare into an A-B comparison. What happens when I run through my, you know, run my application through its paces with my methods working this way. And then if I change the underlying logic to those, what happens in that case? You don't have to change up tests. You don't have to do a whole lot of other stuff. You have the same interface as you essentially the user is think of it as they have the same buttons available to press on your application. It's just now that under the covers, there's more stuff that's going on. And at the end of the day, all that really matters is their input should still get consistent output. What they put in the expectation of what is returned should be correct. So, again, you know, even with private protected public in that the rule of thumb should be need to know basis. Keep things simple. Probably don't use sweeping ideas like all attributes are private and all methods are public and things like that. Take each item, you know, whether it's a method, whether it's a variable or something like that, or, you know, an attribute of a class. Take each of those essentially on a case by case basis and ask yourself, does somebody or some object that's using this object, this class, does it need to have direct access to it? And if not, then don't provide that. And don't be afraid to even within methods. You know, maybe you have like a public method that behind it has multiple private methods. But by doing so, you're hiding the implementation of your class and leaving the interface very clean and simple. And that's it for this one. So we will continue on next time around the challenge for the day. Take a look at your some objects, some classes that you have recently designed or maybe some that you you own essentially and the design of them. And do a quick sanity check. Did you really need to do you need to hide what you hide? And did you need to show what you show for that class? You can do a little bit of cleanup there may require some, you know, some other changes now because if it was public and you take it private, then you got to make sure nothing's calling it. But it may give you a cleaner interface and something easier to maintain in the future. That being said, go out there, 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 North 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. There are two things I want to mention to help you get a little further along in your embracing of the content of developer. One is the book, The Source Code of Happiness. You can find links to it on our page out on the developer North 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 develop a newer dot com. If you would like more information, now go out there and have yourself a great one.