Adam Jensen has a new post to his blog today looking at a solution he's created to be able to access the raw input a user has entered.

I've run into a minor problem, and I'm not sure my solution is particularly ideal. See, the Zend_Form approach described above does a great job of implementing Chris Shiflett's Filter Input, Escape Output principle...user input is filtered for invalid HTML before it's ever saved to the model, and can then be escaped as appropriate in the view layer. But what happens if you need to be able to retrieve the user's original unfiltered input later?

While working with the raw data could be dangerous, he has created a custom model that, through the getters and setters and doing validation/sanitization and the presentation layer rather than behind the scenes. It's not ideal but he's willing to take suggestions...

Fabien Potencier has posted a look at dependency injections - what they are and how they can effect your code (usually for the good).

Dependency Injection is probably one of the most dead simple design pattern I know. And odds are you have probably already used Dependency Injection. But it is also one of the most difficult one to explain well. I think it is partly due to the nonsense examples used in most introductions to Dependency Injection. I have tried to come up with examples that fits the PHP world better. As PHP is a language mainly used for web development, let's take a simple Web example.

His example uses a session variable, setting it to a language preference and wrapping a class around it to handle the getting and setting. The dependency injection comes in when he adds a SessionStorage class into the mix, a tool that could change the place and method where that session information is held. He suggests that the best place to set these kinds of dependencies is usually the constructor but it can be done as a setter or property injection too. It just depends on the need for the script at the time.

In a new blog post Jani Hartikainen shows how to create an abstract model that you can build on when you need to make a dynamic model for your framework application.

In a usual scenario involving models in PHP, you will have some repeating things: You will usually need getters and setters for the model's properties, you will need to be able to construct the model from an SQL query or such, and you'll also need to write SQL queries for the models.

He builds up the three different parts of the abstract model - the getters/setters, fleshing out the model by defining its properties from array values and creating some dynamic SQL (based on property names).

Federico compares two languages in this new post to the PHP::Impact blog today - PHP and Python - in their need for "getters" and "setters".

Python code doesn't typically use the get and set methods so common in PHP. Normally, when writing PHP code, you carefully protect your instance variables by making them private, so callers can only interact with them via getter and setter methods. [...] Python's solution to this problem is more readable, it has a construct called a "property".

He compares two blocks of code that do the same thing - set properties on the object with the PHP side doing a bit more error checking (seemingly) than the Python side. They both apply a title property to a book object.

In this new post from Lars Strojny, there's a discussion of an "antipattern" - using the constructor for more than it was intended, the "verbose constructor".

Constructors are often used to shortcut dependency injection and parameter passing on instantiation. This is a valid practice and often leads to shorter code. [...] Instead of creating a new instance of "Money" and calling three setter, everything can be done compactly in the constructor. [...] So for the money object this works pretty well. The code is easy to read, but wait, the first argument can be grasped easily, the second too, but the third? It is not too obvious that it is a divisor is passed.

He compares three different ways to get the data into the class - the already-mentioned parameters in the constructor, passing an array into the constructor and using full getters/setters to push the data into the right places (with fluent interfaces even!).

According to Felix Geisendorfer's newest post on the Debuggable blog, he thinks that "private and protected methods and properties are one of the most stupid concepts of OOP."

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.

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.

In response to this previous post from Jeff Moore, Tobias Schlitt shares some of his own comments on the subject - mainly that he wholeheartedly agrees.

The usage of interceptors (__get()/__set()/__isset()/__call()) makes your API a lot more readable and comfortable, while maintaining the purpose behind getters and setters: Checking the correctness of values assigned to a property and wrapping around retrieval mechanisms for a property. I personally call the way of maintaining value-correctness for properties through interceptors virtual properties, which fits quite nice I think.

Tobias gives an example of what he means by these "virtual properties" with an illustration from something widely used on the eZ Components libraries - comparing one method of setting text to an object to another (just setting versus the wrappers).

In a recent post to his blog, Jeff Moore advocates the philosophy that, in your OOP application development, you should "let your properties be properties".

Some times there are some ancillary methods to deal with unsetting, checking for existence, setting via an array, or dealing with references in PHP 4. They can really clutter up the definition of a class. That's not good.

[...] I think the idea is to make the class extensible. But PHP is really ok with just setting new properties on a class. So why not just do this?

He argues that getters and setters in a class are less useful than just setting the property yourself. Using the property name as part of the interface, though (like getting the $obj->foo value with $obj->getFoo) is stil clean enough to be useful.