Now that you know what will be treated in this fourth chapter of the series, it's time to learn how to declare and implement public and protected methods with PHP 5 classes. Of course, as always I'm going to address this useful topic by using a hands-on approach, which means that there's a bunch of code samples ahead, waiting patiently for you.

They talk about calling methods globally first and then move into the keyword restrictions. They show the difference between a public method/variable and a protected one, including how to get at the protected members from a child class.

In the last article, I explained how to work with a couple of private properties that partially comprised the API of a basic class, which is useful for saving simple strings to a specified text file.

This part builds on this previous example but changes up the subclass (an instance of DataSaver) to use what they call an "accessor" - a function in the parent that returns the private variable/contstant's current value when called.

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.

• Zend Framework Login: Creating Switching for Front Page
• Zend Framework Login: Creating Logout
• Zend Framework Login: Protected Page
• Zend Framework Login: Fatal error Cannot use object of type stdClass as array
• Zend Framework Login: Creating Authentication
• Zend Framework Login: Creating Form Login
• Zend Framework Login: Preparing Database

Check out their site (or grab their feed) for more PHP-related articles and tutorials.

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.

This morning, I was wondering about how to extend a singleton class such that you could retrieve the new class when retrieving the singleton later. In particular, Zend_Controller_Front is a singleton, but what if I want to extend it later? A number of plugins in the Zend Framework, particularly view helpers and routing functionality, make use of the singleton; would I need to alter all of these later so I could make use of the new subclass?

He gives two code examples to illustrate his point - one that uses the current Zend_Controller_Front implementation to extend an instance and the other with a slightly modified version to do the same. The change is in the declaration of the $_instance value. By making it protected, the differently extended instance will be created. With the normal setting (private) you'll only ever get back the same default Zend_Controller_Front instance.

Check out the comments for some other suggestions as well.