Access Modifiers ... Why?

356 views Asked by At

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

6

There are 6 answers

3
Hans Olsson On

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.

0
AudioBubble On

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).

0
Heinzi On

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.

0
S.Lott On

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

0
David On

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.

0
AudioBubble On

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

  1. 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.
  2. 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".