DevShed has posted the fifth part of their series looking at the visibility keywords on PHP5's object oriented support today. They've already looked at private, public and protected properties in a class, now they look at the use of making methods private to restrict their use/extension.

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.

Alex Netkachov has posted his own response to this opinion on the Typical Programmer on getters and setters in object-oriented applications.

"Do not use getters and setters" looks like a hastily advise, but its meaning is very important and it is "do not break encapsulation", which moves us to the question what the encapsulation is.

He notes that encapsulation is, in essence, hiding parts of the code away so that the user/other coders only see a little bit of the magic that happens. He argues that getters and setters are a valid part of the encapsulation process and that designing a good, easy to use system almost requires them.

According to this new post on the Typical Programmer blog, using getters and setters in your scripts only adds in a bit of unnecessary coupling and complexity to your scripts that you just don't need.

Today most of the popular programming languages support objects, limiting scope, modularity, passing by value, and sophisticated built-in types. There should be no reason to deliberately expose an object's data to the rest of the code because the language can enforce encapsulation and data hiding.

While not specific to PHP, the post does recommend against them because of one simple reason common to all languages that make them possible - they "break the encapsulation OOP offers". For them, they're like a cheat to get around bad coding practices and are not needed to make a successful application work.