A few of my friends have asked me about this recently, so I’ll document it here for others as well.

Visibility refers to how an object property or method can be seen or called. The simplest type, and the default (making it the most common) is public.

A public visibility means there are no restrictions to where the variable or function can be called or modified from.

The next one is protected. A protected visibility only allows it to be seen within the class (OR parent/child class) that it is defined in.

Finally, there is private. A private visibility means only the defining class (not a parent/child) can access it.

So when do you use each type and why? One of the more important concepts or writing OO code is that each component, just like in electronics, management, or any sort of abstract system, essentially has two parts: the internal and external. The internal would be your private/protected, and the external is what the public eye (a user of an iPod, or a customer) would see — which could also loosely be called an interface or API. Note I’m not using the term ‘interface’ programmatic ally, but literally.

Let’s look at the McDonalds franchise for example. Because it’s a franchise, we would also have the protected visibility here, because each store is an extension of the actual McDonalds franchise. There are three types of things going on: public - what the customer can access (reading the menu, ordering food, sitting down) - what the store staff can see and do (customer access, basic store maintenance and management) and finally private, what the higher management controls. The general public cannot see their financial records, or change their menus. You cannot see higher up tasks, because they are internal components that you need not worry about. The public interface is your gateway to use those hidden components.

However, there is an ongoing debate that this is all useless for PHP, because anybody can see the source. Even if something is declared as private, you can go read and modify it. Yes this is true, but it can still be used to help fine tune your application design. Prior to PHP 5, the standard was to prefix private/protected data with an underscore. With the added public/protected/private keywords, PHP will generate an error if you attempt to access a private variable outside of the class which is great for early design stages.

The more complex question now is when do you use private/protected? If you declare something as private, how do you know somebody won’t need to extend and modify its functionality (which protected would allow). There is no set in stone answer for this unfortunately. My general rule of thumb is if I’m writing code that I expect someone to extend (for example, a framework, or basic library to be used), then I will use protected for any areas that may need to be flexible. I set private for things which really are internal, and child classes won’t or shouldn’t need to modify. Then, the public side is how you use the class.

Each class should carry out one very specific task. The more specific your classes are, the more you can reuse them. The interface for using the class should be public functions, and everything else should be private or at least protected. When I look at the class, or any other class, all I have to look at are the public functions to see how it needs to be used. And that’s how it should be, because it makes the code much more reusable and flexible.

Keeping the interface separate from the internals is very important for a proper application design.