I’ve been asked this a lot lately from lots of different people:

What’s the difference between public, private, protected etc?

It’s quite important to understand that in good class design, these declarations will help you ensure encapsulation and appropriate logic where it’s supposed to be to do the job it’s got to do. Encapsulation is important so that work flow is contained, manageable and expandable.

The most important thing to remember is:

The interface a class exposes should be simple, small and expressive as possible.

So here are some definitions:

Public: These methods and variables are exposed to the full scope of your application and any 3rd party applications that integrate with it.

Private: These methods and variables are exposed only to the class they are declared in.

Protected: These methods and variables are exposed to the class they are declared in and any classes that inherit from it.

Final: These methods (not applicable to variables, use constants instead) and are independant from public, private and protected. You can have a “public final function” which means that you can’t override that method with one from a child class.

So when should we use these functions?

Well here’s an example of constructing a user object.

You need some form of access to your class/component so something’s got to be public! Your public method is probably “public function getUser($id){}”.

So here we have your public method to fetch a user. We now need to do some stuff inside it to actually retrieve the user. Thing is, do we want other people to manipulate this functionality? No because it makes our interface complex and messy. It also means that anyone can mess up your encapsulation. This is generally bad.

Question is then, how do we do that? Well that’s where your private functions come in to play. So you have public function getUser($id){} but we want to keep the process of connecting to a database away from the interface functions. So inside your getUser function we have… $this->_getDBConnection(){} that will call “private function _getDBConnection(){}” This means that only functions inside that class can use that function.

One problem though, the User object has child classes that inherit from it and they all need to access the database connection… uh oh, only functions in that class can access the connection function. Oh noes! What do we do?? I know… change that function to: protected function _getDBConnection(){}! What this does is makes the function available for that class and any class that inherits from it. Result!

Next problem, all the children may overide the DB Connection function by declaring it at the child level. You as a developer say – ummm no thanks. Don’t do that, you’ll break stuff. So you can make the function “final”. final function _getDBConnection(){}. This stops anyone creating child classes and overriding the function in the parent. Even if they declare it to try and do so – it will be ignored and bork. There is however a rather good argument that if you’re ever in a position to do this with your development team, its possibly not final functions you need, but new colleagues…….

It can however be useful if you’re creating code that is to be published to be used in the open source arena where a function must not be overidden due to core logic etc. Again, some would suggest that if this is the case, your architecture is not as effective as it should be.

Code example to come at some point when I’ve bothered to install a decent code plugin that doesn’t do stupid things in the editor 🙂 Hope this helps!