The PHP::Impact blog has a new tutorial posted today with a look at a refactoring of the front controller of the Zend Framework to make it a bit more manageable.

One of the most fundamental decision in object design is deciding where to put responsibilities. No one, and I mean no one, gets it right the first time. That's why refactoring is so important. As Kent Beck puts it, refactoring is the process of taking a system and adding to its value, not by changing its behaviour but by giving it more of these qualities that enable us to continue developing at speed.

He follows the "extract" refactoring method that makes things simpler by removing unneeded parts of the code (in favor of an interchangeable external "extract class". He removes seven methods from the class and splits them off into their own. This reduces the controller down to a more manageable size and takes a lot of the complexity out.

In an effort to breathe as much life into an old bit of software he was having to update, Harry Roberts worked up a list of things that he sees can make things a bit more "programmer friendly" when it comes to using classes, methods and interfaces in your code.

His list of four is:

• Doc Comments
• Flexible Parameters
• Use method Entry contracts
• Be Stateful and Refactor

The "Doc Comments" is pretty obvious, but some of the others need a bit more explaining. Being flexible with your parameters is more about requiring the least from a developer, "entry contracts" being the restrictions to let the developer know what you're expecting and refactoring commonly used functionality into a easy, single point of contact.

Roy Ganor has posted a new article on the Zend Developer Zone about code refactoring, what it's good for and how it can help you and your code.

At first, refactoring seemed to me to be magic, over the years I have come to view it as more of a trick, and today refactoring is integrated into my development environment and used frequently and quickly. Using the refactoring functionality, in addition to other tools, I can sculpt the code to improve legibility and maintainability.

He talks about why PHP developers should jump on getting to refactoring their code, the different forms of refactoring, code examples showing it at work and some development tools/resources you can use to dig a little deeper.

In a new blog entry today, Matthew Weir O'Phinney talks about updates (and refactoring) that he's done to a PEAR package he's developed, File_Fortune.

Over the past few evenings, I've refactored File_Fortune to have it implement Iterator, Countable, and ArrayAccess -- basically allowing it to act like an array for most intents and purposes. As a result, I've eliminated the need for the File_Fortune_Writer package, and greatly simplified the usage.

The package is designed to make an interface between the casual PHP user and the fortune files common on most *nix machines. To illustrate he update, he includes some code that grabs the fortune file, parses it to grab a random one and echoes them out. Also included is the save() method so you can add your own to the list easily.

Continuing on with his look at his OpenID library and its implementation, Padraic Brady has two new posts with more of the story.

From the first post:

As a follow on from my previous entry about OpenID in the Zend Framework, I've been in brief contact with Dmitry Stogov across a scattering of emails. Dmitry posted his OpenID proposal for the framework over at the Proposals Wiki earlier in the week. [...] It's actually very hard to comment constructively rather than simply handing over my code which probably says a lot more all by itself. [...] Anyway, I've agreed to port my OpenID library to PEAR as a PHP5 package. I checked with the mailing list, and the approach I've taken in splitting the library across a number of freestanding components hasn't seen any objections. On the flipside, it does help by providing upgrades to existing PEAR Encryption packages which are not yet migrated to PHP5 versions.

And from post number two:

Over the weekend, I managed to grab a few hours to dig around my OpenID library with the ultimate development tools: patience and experimentation. [...] What I've refactored towards is a splitting of the OpenID process based on three categories: Request, Redirect, Response.

Matthew Weir O'Phinney has been hard a towkr these past few months on his own contribution to the Zend Framework, the Zend_XmlRpc_Server package. He talks about it on his latest blog posting today.

In the past couple weeks, I've refactored it to push the class/function reflection into Zend_Server_Reflection, and, in doing so, noted that there were further areas for refactoring into additional helper classes. Currently, it now has classes for the Request, Response, and Faults, and all actual XML wrangling is done in those, making the server basically XML-agnostic.

The refactoring of the code also had another positive side effect - it made it much simpler for him to write up the tests to ensure the correct functionality of the package. He includes an example of the use of the package, a fake request with various methods in the comb, brush, and pick categories.

If you'd like to mess with the extension yourself, check out the Zend Framework subversion repository and grab the latest incubation distribution.

Felix Geisendorfer shares, in this new post to the ThinkingPHP blog, some of his experiences with writing his code using test driven development.

So far I've had tons of fun trying to create php code using test driven development. It caused my code to become a lot more structured/consistent because writing the tests shows you interfaces problems right away. This is because the process of writing the test forces you to think a lot more about *how* you want to use some class / piece of code vs. your traditional "how can I get task x done"-thinking.

He also points out another benefit - it makes refactoring the code even easier (so there's more of a likelyhood that you'll use it again and again). He talks specifics about a library that he's been working on and the processes he's gone through to make things work with the testing versus his normal development cycle.