In a new post to his blog Chris Hartjes, promoter of all things testing, looks a a method for testing constructors - an effective way to validate the things that happen when your objects are generated.

If you have a PHP application that makes heavy use of objects (which is probably 95% of you reading this) then you will have objects with constructor methods in them. It is also very likely that there is some stuff going on in those constructors. So how do you test things like this?

He includes a sample constructor that creates a container, pulls out some configuration values and reassigns them to class properties. He first tests that these properties have been set correctly by mocking out the object and overriding the configuration settings in the (dependency injection) container.

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).

Tobias Schlitt has posted a handy tip about using the Reflection API in PHP5 - specifically its accessing of private properties in a class.

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.

Stefan Mischook shares a little question and answer he had recently concerning object properties in PHP.

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.

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.

In a brief new post, Mike Wallner talks about some of the discussion surrounding overloaded array properties lately and something he's discovered about it.

As arrays are the only complex types that are passed by value (resources don't really count here) the solution to described problem is simple: use an object; either an instance of stdClass or ArrayObject will do well, depending if you want to use array index notation.

He includes two code examples, one just trying to overload it in a class with __get (yielding an error) and the other using the constructor to pass an ArrayObject out first, allowing for error-free assignment.

Continuing on in their "PHP functions" series today, DevShed has posted this next step up the ladder, getting more advanced with the functions they're working with. This time, there's a focus on functions inside classes and creating the classes around them (a sort of introduction to object-oriented programming).

Continuing our PHP functions article, we move on to creating classes. Let me say right at the start that you can write perfectly effective and useful PHP code without creating classes or going into object oriented programming. Object oriented programming can be very powerful and PHP programmers are increasingly taking advantage of these capabilities, which have been greatly expanded since PHP4.

They start with the creation of a simple class - a human class with two $legs and two $arms. They show a simple display of this data and add another attribute to the class, one for hair color. They then capture the output they've been creating inside a function, report, and show how to execute it. Finally, they show how to use the special function that runs when the object is created - the constructor.