There's been a few articles posted on various blogs in the PHP community recently about the "most correct" usage of the "private" scope in your PHP applications. As with any feature of just about any language out there, there's people on both sides of the fence. Here's the ones that have weighed in so far:

• Brandon Savage's initial post (an excerpt from his upcoming "Do This, Not That" book)
• A response to this from Anthony Ferrara
• Brandon's own response to comments on his previous article
• This new post from Larry Garfield and some of his experience from the Drupal world

Various topics come up during these posts including static coupling, using interfaces versus inheritance, wrapper classes and developer intent.

In the latest post to his site Andrew Podner takes a quick look at something you don't see too much in PHP applications but is a familiar concept to some coming in to the language from others - using "final" to prevent overrides of the code in your classes.

In a previous post about inheritance, I showed you how to extend a class. One aspect of extending classes that wasn't fully covered was the idea of overriding a method in a class. You can override a method (function) from the base class by simply redefining the method in the child class. [...] There are times though, when you do not want a method to ever be overridden. There may even be cases where you do not want a class to be extended.

His example shows how to use this "final" keyword on a database class, protecting a method (getRecord) that could potentially break the application if changed. This would then give the developer trying to extend the class an error noting that that method cannot be overridden. One thing to note, if you're going to use "final" in your code, be sure you know what you're doing. More often than not, you probably just want something like "private" or "protected" (see this post for a bit more explanation).

Matthew Weier O'Phinney has a new post to his blog today looking at visibility in OOP in PHP - less about the features the language offers and more about the theory of their use.

I'm a big proponent of object oriented programming. OOP done right helps ease code maintenance and enables code re-use. Starting in PHP, OOP enthusiasts got a whole bunch of new tools, and new tools keep coming into the language for us with each minor release. One feature that has had a huge impact on frameworks and libraries has been available since the earliest PHP 5 versions: visibility.

He covers a bit of the syntax and features of public, private and protected and mentions a keyword not often seen in PHP applications - final. The reason all of this came up was work on annotation support in Zend Framework 2 and some difficulty in integrating it with Doctrine support. The "final" status of the class was part of the problem, and after a a lot of copy & pasting he decided on a different tactic - using its public API to try to work around the problem.

In sum: because the class in question was marked final and had private members, I found myself forced to think critically about what I wanted to accomplish, and then thoroughly understand the public API to see how I might accomplish that task without the ability to extend.

In his recent post Gonzalo Ayuso shares some "strange behavior" he found with method visibility in his recent development:

Normally I feel very comfortable with PHP, but not all is good. There's some things I don't like. One is the lack of real annotations and another one is this rare behaviour with visibility within the OO. Let me explain this a little bit.

The problem came up as a part of a recent refactor where a protected method, when called from an object injected into another class, threw an "access" error that it was called from the wrong context. He reported it as a bug but was reminded of how PHP handles exposure - on the class level, not the instance of a class level.

From RubySource.com there's a new post from a confessed developer who moved from PHP to Ruby about PHP's private visibility rules and how they compare to Ruby's.

Alright class - today I'm here to talk about the differences and similarities that PHP and Ruby have when it comes to object properties, methods, and their visibility - how you create variables inside classes, and how you can interact with them.

He compares the private properties in PHP classes to the corresponding handling in Ruby, including the getters and setters to go with them. There's also a look at class visibility settings in Ruby.

If you were a fan of the PHP quizes that Mark van der Velden has posted in the past, you'll be happy to know he's come back with part four of the series after a bit of a hiatus.

It has been a while, but here is part 4 of the PHP Quiz series! A few questions to crack your brain about, or perhaps you know them all? Try them and find out! Also do read the idea behind these quizzes, here: The PHP Quiz series

In this quiz he tests your knowledge of class visibility, fluent method handling, class extension, strptime and a tricky "for" loop. Take the quiz and see how you do.

Wes Shell has posted a new tutorial to his blog today looking at encapsulation in PHP development - containing parts of the script to make them easier to work with as a whole.

In order to understand the purpose of encapsulation you first need to understand the purpose of classes. [...] In order for them to be used properly as they were designed, you will need to limit how users of the class can interact with those characteristics and functionality.

He looks at the visibility modifiers (public/private/protected), interface functions and some sample code showing how to use them in a simple class to work with a Person's set of data.

In this recent post to his blog Chance Garcia looks at visibility and inheritance in PHP applications. Specifically, it references a question that came up on IRC about the "default" visibility for methods and the open/closed principle.

Out of the whole discussion, here is the points I got (aka understood) out of it. Please correct me in the comments if I'm off base in any way.

There's two points he makes in the remainder of the post:

• Methods should only be public when necessary.
• Private methods allow you to preserve the class' core functionality.

There's also a bit of code included to illustrate some of his points.

DevShed finishes off their series looking a private, public and protected variables and methods in classes with this final look a private methods in PHP5 object-oriented programming.

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.

DevShed continues their series looking at variable scoping in PHP5 classes with this new look at using the public and protected keywords to "restrict member visibility".

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.