Access Modifiers ... Why?

Question

Ok so I was just thinking to myself why do programmers stress so much when it comes down to Access Modifiers within OOP.

Lets take this code for example / PHP!

class StackOverflow
{
    private var $web_address;

    public function setWebAddress(){/*...*/}
}

Because web_address is private it cannot be changed by $object->web_address = 'w.e.', but the fact that that Variable will only ever change is if your programme does $object->web_address = 'w.e.';

If within my application I wanted a variable not to be changed, then I would make my application so that my programming does not have the code to change it, therefore it would never be changed ?

So my question is: What are the major rules and reasons in using private / protected / non-public entities

score 3 · Answer 1 · answered Sep 14 '10 at 14:45

Because (ideally), a class should have two parts:

an interface exposed to the rest of the world, a manifest of how others can talk to it. Example in a filehandle class: String read(int bytes). Of course this has to be public, (one/the) main purpose of our class is to provide this functionality.
internal state, which noone but the instance itself should (have to) care about. Example in a filehandle class: private String buffer. This can and should be hidden from the rest of the world: They have no buisness with it, it's an implementation detail.

This is even done in language without access modifiers, e.g. Python - except that we don't force people to respect privacy (and remember, they can always use reflection anyway - encapsulation can never be 100% enforced) but prefix private members with _ to indicate "you shouldn't touch this; if you want to mess with it, do at your own risk".

score 2 · Answer 2 · answered Sep 14 '10 at 14:31

2

Because you might not be the only developer in your project and the other developers might not know that they shouldn't change it. Or you might forget etc.

It makes it easy to spot (even the compiler can spot it) when you're doing something that someone has said would be a bad idea.

answered Sep 14 '10 at 14:31

Hans Olsson

51,774
14
88
111

@S.Lott: Comments might not be read (or read and forgotten) and I see it as that if something is private it might be easier to write the unit tests since you can control the states the object will be in when it's being called, so you might not have to write as many tests (or less complicated ones). – Hans Olsson Sep 14 '10 at 20:54
All in all, when possible, I try to write my code with the assumption that I'll hand it over to a complete beginner to maintain it, so I try to write it to be as easy as possible to use correctly. I think that minimizing the public interface to my classes helps avoid them being used in the wrong way, especially by the all too many developers I've met that don't seem to like to read either comments or documentation of any kind :) – Hans Olsson Sep 14 '10 at 20:54
"Comments might not be read" How sad. Find new colleagues to work with. – S.Lott Sep 14 '10 at 23:01

score 2 · Answer 3 · answered Sep 14 '10 at 14:39

So my question is: What are the major rules and reasons in using private / protected / non-public entities

In Python, there are no access modifiers.

So the reasons are actually language-specific. You might want to update your question slightly to reflect this.

It's a fairly common question about Python. Many programmers from Java or C++ (or other) backgrounds like to think deeply about this. When they learn Python, there's really no deep thinking. The operating principle is

We're all adults here

It's not clear who -- precisely -- the access modifiers help. In Lakos' book, Large-Scale Software Design, there's a long discussion of "protected", since the semantics of protected make subclasses and client interfaces a bit murky.

http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620

score 0 · Answer 4 · answered Sep 14 '10 at 14:32

Access modifiers is a tool for defensive programming strategy. You protect your code consciously against your own stupid errors (when you forget something after a while, didn't understand something correctly or just haven't had enough coffee).

score 0 · Answer 5 · answered Sep 14 '10 at 14:33

You keep yourself from accidentally executing $object->web_address = 'w.e.';. This might seem unnecessary at the moment, but it won't be unnecessary if

two month later you want to change something in the project (and forgot all about the fact that web_address should not be changed directly) or
your project has many thousand lines of code and you simply cannot remember which field you are "allowed" to set directly and which ones require a setter method.

score 0 · Answer 6 · answered Sep 14 '10 at 14:39

Just because a class has "something" doesn't mean it should expose that something. The class should implement its contract/interface/whatever you want to call it, but in doing so it could easily have all kinds of internal members/methods that don't need to be (and by all rights shouldn't be) known outside of that class.

Sure, you could write the rest of your application to just deal with it anyway, but that's not really considered good design.

Access Modifiers ... Why?

6 Answers6