This is a thought I first shared at CakeFest Orlando this year, but could not explain properly at the time.

He illustrates with an example of a protected "balance" variable in a BankAccount class. Sure, it's marked as private but less skilled programmers might not use it that way. He recommends a method without the getters/setters to help make the usage of the variable a bit simpler. He also suggests that using protected/private scoping helps to promote "crappy code" - using them to provide a sort of protection for code that you either don't want getting used or hiding it away so the API can't get at it.

It's time to leap forward and tackle this final article of the series, which will be focused on covering some additional aspects concerning the use of this kind of class method. In addition, I'll teach you how to utilize the "final" keyword, which is included with PHP 5, to prevent the methods of a specific class from being overridden by any subclass.

They work from a hands-on example to show how they can work with private methods (expanding a bit from last time) and how to use the "final" keyword to restrict any and all modification for a method.

Of course, when it comes to specifying how visible a certain class property or method will be, you know that PHP 5 permits you to work with three distinct levels of access, called "public," "protected," and "private" respectively. [...] As you may have noticed, however, I've not taught you how to define private methods yet, which is something that can definitely be very useful if you want to restrict the access to your classes from the outside more severely.

The tutorial shows the creation of a class with private properties and then expands it to include a private method. Then they call it from an object, an example of the error PHP kicks back is there too. He also includes the concept of a "getter" to call the private function from a public one.

I remember when PHP5 first came out having 'discussions' with a number of people who insisted that PHP5 was way better than 4. [...] Basically, intentions were made clearer with things like "public protected private" (PPP),but I have not yet seen any web project get done faster or dare I say even much *better* due to those sorts of things. [...] This isn't specifically saying PPP is necessarily bad, but that PHP could have addressed the issue in a fashion more suitable to dynamic languages. Keep reading for an example.

His comparison is to how Groovy handles properties in a class - everything is private unless declared otherwise. This could be ported (somewhat) over to PHP and would eliminate the need to search&replace all over the code for the right variables.

One of the most useful features that was introduced into the improved object model of PHP 5 is "member visibility." It provides PHP developers with the ability to specify the level of access each data member of a class will have in the context of a given application.

They review the other two keywords (public/protected) before venturing on to the use of "private" to protect, but allow access to, methods and properties in a parent class.

The previous concept can also be applied successfully when it comes to defining the visibility of properties and methods in PHP classes. [...] Using the jargon of object-oriented programming, this capacity is widely known as member visibility. This capacity allows PHP programmers to establish whether the set of methods and properties of a specific class will be public, protected, or private.

They start more generally by looking at how to set up the variables globally and then move down the line talking about restrictions (private/protected/public) and how to get to them in the scripts outside the class.

Everybody who writes object-oriented code knows about constructors. You need them so the program knows how to instantiate objects, right? And you especially need them when a lot of things have to be done while instantiating an object. [...] So why would I be skeptical of public constructors?

The solution, as he sees it, is to make a "constructor" that's actually called statically with parameters that returns an instance of the class it's in as well as performing the action. He argues that this can help make the code much more readable for some types of method calls.

There are many benefits of inheritance with PHP, the most common is simplifying and reducing instances of redundant code. Class inheritance may sound complicated, but think of it this way. Consider a tree. A tree is made up of many parts, such as the roots that reside in the ground, the trunk, bark, branches, leaves, etc. Essentially inheritance is a connection between a child and its parent.

They choose to go with a "car" illustration instead and show how a child of the Product class (Car) can access the private properties of the parent. They also include an example of it in action with a bit of HTML output.

I recently stumbled over reflecting private properties in PHP again. As you might know, this was not possible until now and if you tried this [code] PHP thanked it to you with this [error that is cannot access a non-public member].

He notes that, while the behaviour is correct, it still makes things like metaprogramming impossible. So, what's a developer to do? Patch it of course! Tobias and Derick Rethans persuaded two other developers (Derick and Marcus Borger) to include a patch that allows the Reflection API to see these private variables.

To make it work, you have to use the setAccessible method on the Reflection object to set which of the properties you want to be able to get at.

The question asked about accessing properties outside the class and/or defining them as protected/private to prevent it. Stefan's response was basically:

Many OO techniques are designed for situations where you will have more than one programmer involved, now or later. By declaring variables as protected or private, you are adding security to the code base by forcing the use of getter and setter methods where you can control how objects are used.