Why is public private protected so important?

Question

People keep telling me I should be using public, private, or protected access modifiers in front of all of my class properties and methods. I really don't understand why. I'm new so bear with me, but the way I see it is this:

• I am the only one who will work on my code. Not a team.

• I already know what everything means, plus using an editor that tells me all the declared vars and properties, I know I'm not going to step on my used variables.

One of the explanations I get is that it "protects or hides" your code from people who could see it.....but in PHP there's no way that I know of for a user to see your code in the first place, who am I hiding it from? If they CAN see my code then they are either a hacker or they are in my account so I can't stop them anyway.

I can understand if I were working with huge code on a team, but for small things it seems unnecessary.

Answer 1

"Encapsulation", as it's called, doesn't protect your code from people. Anyone who has access to your source code already knows what's there. And if they don't have the source, then they can't do anything special with your public stuff either.

What it does is prevent code that's not in the class (and therefore shouldn't have to know how the class does things) from accidentally mucking around with internal variables. That way, the variables are less likely to wind up with wacky values -- and when they do, you can point to the class and say the broken code is there, rather than halfway across the app.

Note, in order for this to be useful at all, you can't just have trivial setters for everything like public function setX($x) { $this->x = $x; } -- that defeats the whole purpose. Your object should be as much of a "black box" as you can make it, and that partly means outside code should be able to see and modify as little of its internal state as possible. Let the class manage its own state, and have methods that take the other stuff they need to do their job. (A semi-obvious exception here would be types whose main purpose is to ferry data around, but even there you should limit access to anything that's not that data, and the setters for such data ideally would validate it and such.)

Answer 2

You're not "hiding" your code from anybody, that's nonsense.

What protected and private properties are doing is to tell PHP how you intend to use them. When you create a class, you should usually have an idea of how you want that class to be used. You will have public parts, which other code can interact with, and other parts that you do not want to have other code access directly. Typically you want to restrict the public parts of a class to a very small set of well defined methods which are not going to change. Because once you are using them in other parts of your code, changing them becomes a pain. All the private and protected stuff should only be accessed within the class itself, so changing it around is less of a problem later.

If you're the only one working on the code you may say it's as easy as simply not using the "private parts". But you are going to make mistakes, and you are going to forget what part belongs where over time. Marking these properties explicitly as protected or private lets PHP help you not violate your own "terms of use". It's the difference between a mental note of "don't touch this" and actually putting a lock on something.

Answer 3

The main thing it is required is for code encapsulation and consistency, so you cold have consistent interface around your code.

When you are creating your classes, you are indicating what parts you want to be public-private-protected, you also thinking ahead and architecturing your application how data should interact with other classes,s cope, and that's also good thing to use for small project.

While for small projects is looks useless, i highly recommend start using it, and grow your habit to use them, when you start using visibility modifiers you will see that they are pretty useful.

Answer 4

I have found that the operators help you to not step on your own foot. As my applications have grown bigger I have sometimes lost sight of my original thoughts when making some of the earlier classes and having the access modifiers to protect me has helped. It also helps to organize your code better so that you understand what is what and don't end up programming spaghetti code. Also, in the off chance that you end up programming for somebody else someday in a situation where someone may look at your code down the line, you won't have be embarrassed by your coding style since getting used to using the constructs of the language to structure your code will help you to improve your coding style. The constructs are there, so why not use them?

So for your specific situation at the moment I would say that all you are doing at the moment is hiding it from your future self so that you wont be like "Hmm...I made this class for one of my projects 2 years ago and I will use it now" and then go trying to mess with the internals in a way they weren't meant to be messed with which could cause problems for a reason you might not be able to remember.

It is true that unless you are working with a compiled language like C# or C++ the modifiers won't hide your actual code from a potential end user. When making a library in those kind of languages the modifiers become more important because they actually hiding your code from the end user and if you end up working on a proprietary system that can be important (albeit annoying for the end user sometimes).