Brandon Savage has taken some of the good practices in object oriented application development and related them to some of the things that the government can teach you about them:

However, the ubiquity of governments around the world also gives us a unique opportunity to learn some lessons from them as developers, particularly about principles of object oriented programming. Governments serve as perfet object lessons (pun intended), demonstrating some of the good, the bad, and the ugly object-oriented practices we see.

He looks at five topics - abstraction, encapsulation, implementation of dumb objects, decoupling and the concept of "one class, one responsibility".

Brandon Savage has posted the answers to some questions that were raised by a previous post of his on object-oriented development and some best practices. In this new post, he answers the questions:

• "Often times when a developer gives each object only one responsibility, they tightly couple objects together." Can you explain?
• I do not know about dependency injection '" do you have any links that do not require subscription?
• Can you please explain 'one object '" one job' concept?

Each question is answered, sometimes with code included, to help resolve any confusion about how to correct use object oriented practices in your applications.

On the Ibuildings blog today Dennis-Jan Broerse has posted the first part of a series he's doing on moving a development team up into the world of object oriented programming.

Being a trainer for Ibuildings, I noticed that the main topic of almost every course plan for customers is object oriented programming. So OO is popular and demand for it is rising. However, while PHP support for OO has been present for a couple of years still many companies that I visit are maintaining and developing procedural applications.

He talks some about how he tries to promote the OOP way of doing things and defines one of the major hindrances for companies to try to move their development towards it - time. The next part of his series will look at ways to help with this.

On the Blue Parabola blog, Matthew Turland takes a look at object-oriented programming and what core concepts lie at its heart.

What is object-oriented programming? The acronym OOP has become a bit of a buzzword in the current age of programming, to the point where the waters of its definition have become rather murky. [...] PHP may not be object-oriented, but from a purist perspective, neither is Java. What do I mean by "purist perspective?" Plain and simple: everything is either an object or a message being passed between objects (where message parameters are also objects).

He mentions one of the first languages to support objects (Simula) and the four fundamental concepts that would make a language truly OOP - abstraction, inheritance, encapsulation, polymorphism. Its his opinion, though, that while its good for languages to adhere to these four principles as much as they can, discussions about how well they adhere to them is usually just "spinning your wheels" and don't have much use.

One complaint that Michael Kimsal has about the PHP language - "PHP is *not* object oriented":

Goodness. I like PHP. I use it a lot. I've been using it since early 1996. I'm Zend Certified, have done billion dollar ecommerce projects in PHP, and like to think I know a little bit about PHP. It is *NOT* "object oriented". I wish people would quit saying it. Perhaps there's a need to impress non PHP people, or to try to get across the idea that PHP supports objects. Maybe that's fair, but I don't think so.

His reasoning is that, despite the phrase "object oriented" being applied to PHP, its functionality does not hinge on objects. He suggests a "more correct" term to replace it - "object capable". This shows that PHP can use objects but, because of its procedural roots, doesn't have to.

The first step towards a full, stable release of the next version of PHP - 5.3 - has officially been made - the first beta (PHP 5.3beta1) has been released and is now available for download.

The biggest change is dropping of OO functionality in closures as full OO support for closures is planed for a later release than PHP 5.3.0. See http://wiki.php.net/rfc/closures/removal-of-this. This release marks the begin of a feature freeze and bug fix only phase. If in doubt whether your change is a bugfix please run it by Lukas and me.

You can download the packages here:

• tar.bz archive
• tar.gz archive
• Winodws builds

NETTUTS.com has posted an introduction (using the Car analogy, of course) to teach you how to use the basics of object-oriented programming in PHP.

PHP is so much more than a scripting language. It's a full-fledged language capable of building very complex applications. By harnessing the full power of Object Oriented Programming, you can reduce the amount of time you spend coding and use it to build better websites. This tutorial will show you how.

They explain objects, inheritance, encapsulation and polymorphism briefly before "getting their hands dirty" with some actual OOP PHP code. Their code example sets up a thumbnailer class - one that takes in an image, a height/width you want to resize it to (as properties) and splits it back out the other side.

As always, you can grab the source or view the demo to see it work.

In a new post to his blog, Brandon Savage makes a suggestion that could help in maintenance and debugging down the road - keep those superglobals out of your classes.

Let's ignore the security implications of the above code for just a moment, and focus on just the use of the superglobal. By using the $_POST superglobal array, we're effectively doing two things [in the example code]: relying on the field names and limiting code reuse.

He shows how to refactor the example into something a bit more reusable by changing the method call to pass in the given username and password instead of looking to the global for it. He does note, however, that there are some more correct uses for those superglobals:

There are some legitimate uses of superglobals in classes. One example is the use of the $_SESSION superglobal, which is often used for things like a user object. But I urge you to do so sparingly, when appropriate, rather than relying heavily on superglobals which are subject to change and may not give you the data you expect.

On the NETTUTS.com site, there's a new tutorial that looks to be a basic introduction to the world of Object-oriented programming in PHP.

Numerous examples from robots to bicycles have been offered as "easy" explanations of what OOP is. I've opted to show you how OOP works with a real-life example, for a programmer. By creating a MySQL CRUD class you can easily create, read, update and delete entries in any of your projects, regardless of how the database is designed.

Their CRUD example not only serves as an introduction to OOP, but can also be an introduction to MySQL support for those that haven't used it before. They create six functions - the four for CRUD and a connect and disconnect. The full source is available for download too.

In a new article to his blog, Ryan Campbell has expressed some concerns in the amounts of memory that some of the object oriented practices in PHP are using these days.

It's hard to imagine pushing the limits of object oriented PHP so far that your web servers choke, but the truth is those limits are reached faster than you think. [...] While replacing objects with arrays when possible makes things a little better, the most performance friendly approach involves appending strings. For your convenience, we've run some tests that measure page execution times and memory usage to create the following guideline to help you plan out what areas of your code may have to break away from an object oriented nature.

He shares some benchmarks of the memory use for different variable types - strings, arrays and objects - giving load times and the amounts of memory used. He mentions three workarounds that could help (unset, static methods and paging) reduce the memory consumption of your script.