View Full Version : Private/public
marmin
16-04-2005, 02:50 PM
Hi-
Why should I use private , public and protected sections in my classes- why just not make everything public? Maybe a silly question but I want to know. Thanks..
Harry Hunt
16-04-2005, 03:08 PM
Hi-
Why should I use private , public and protected sections in my classes- why just not make everything public? Maybe a silly question but I want to know. Thanks..
This concept is called "information hiding" and it's one of the most important concepts of object oriented programming.
When defining an object, think of it as building a machine. The machine has levers and buttons on the outside (for the user to handle, these are your "public" declarations) and relays, transistors, etc. on the inside (these are you "private" declaration).
"information hiding" essentially means that you only expose as much of your object as you really have to. You wouldn't want the machine operator to play around with the relays and transistors and it's the same with your objects.
The private declarations define the "internal state" of your object and if that was accessible from the outside, you'd very likely get into trouble.
Imagine you're writing an object that does some simple decryption and encryption with a static key. That key is generated when the object is created. During the life-span of that object, it will always use that key to decrypt and encrypt string. If it was possible to change the key from outside the object, the object would suddenly stop doing what it's supposed to do. It would return string that aren't properly decrypted or in the worst case it might even crash.
Accidently assigning values to variables that should not be changed is a common source for bugs, and information hiding will help you prevent those bugs.
Also, all variables, properties and methods you declare publicly will become part of that object's "public interface" which means that if you change any of those, you'll have to change the program that invokes that object. However, you can change the private variables any way you want and it won't make a difference.
marmin
16-04-2005, 03:17 PM
Thanks for the quick reply!
quote: You wouldn't want the machine operator to play around with the relays and transistors and it's the same with your objects.
Yeah, but I am the programmer of the object.. I know what I do with the object, I don't use the relays in a wrong manner. So, forgive me for being critical, I have a hard time to understand why things have to get Private. Has it also to do with memory usage?
{MSX}
16-04-2005, 03:39 PM
Yeah, but I am the programmer of the object.. I know what I do with the object, I don't use the relays in a wrong manner. So, forgive me for being critical, I have a hard time to understand why things have to get Private. Has it also to do with memory usage?
That's true when you have very few objects.. when you have many of them, on different projects, etc, etc. you must keep in mind all details of your projects. This is possible of course, but it's not good.. the more things you have to keep in mind, the more likely you'll insert a bug.
Informatio hiding also helps to insert checks on your code..
For example, you have a value that can range from 0 to 30. If the value is public, you (or other developers) will be able to put wrong values in it. All of the developers must keep in mind that that particular field has a constraint. On big projects (but also on small ones), this leads to Very Bad Things.
Instead if you incapsulate the value, you can create a setValue method that sets the value only if it's correct. In this way you don't need anymore to remember that particular constraint.
Also, information hiding helps by giving the programmer a simplified view of the program. Think of the internet sockets for example: they have a relatively easy API (our public part), made of few calls, but internally they've hundreds of procedures, codes, etc, etc. If all of this would be public, we'll end up in a great chaos.
Maybe you think that, since you're the only programmer you know your code. This is wrong in many way.. You never know if someone will read/work on your code. And you yourself could need to work on your code after say an year and discover that you forgot everything..
I give great attention to this aspects.. I try always think of objects as an entity with an interface. I spend lots of time to think on how objects should comunicate each other, calling each other methods etc, etc.
Harry Hunt
16-04-2005, 03:45 PM
Well, first of all, object oriented programming is commonly used when there's more than one programmer working on a project. And your team mates may not be as familiar with your objects as yourself.
Also, what if you're working on a project for more than a year? Do you still know how the objects work that you wrote many months ago?
But most importantly: the only reason why programs have bugs is because programmers make mistakes. Information hiding helps you avoid some mistakes and it will therefore also help you reduce the number of bugs in your code.
Sure, you can make all your declarations public just like you can use only global variables, not use naming conventions or formatting guides, etc... the only rules you have to follow are those that your compiler will "enforce", but if you want to write readable, secure and stable code, you should use private declarations where necessary, avoid global variables and follow naming conventions.
Another reason for using private/public/protected declarations is inheritance. Privately declared variables will be invisible in all inherited objects.
marmin
16-04-2005, 04:57 PM
OK, thanks, highly informative. :P
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.