Once I realized what he was doing, I realized that the Strategy pattern was applicable in this case…but his chosen example was dumb and one that I wouldn't have used to demonstrate things. As expected, he told me to supply a sample of a better way. I did, telling him that the sample would be better if he didn't mash the logging level together with the message.

Included in the post is sample code, first showing the initial version of the logging class, complete with accompanying tests. Following that, he shows how to refactor it into something using the Strategy pattern, replacing the logging type switch statement with protected methods for each logging message type (critical, notice, etc).

"The Art of Readable Code" was written by Dustin Bowell and Trevor Foucher and basically focuses on concepts and suggestions to make you code not just readable, but comprehendible by other developers, or as the author's suggest, yourself in six months. Code readability is a topic that I truly believe the PHP community does not focus enough on and i really wanted a look at this book to see what kind of ideas it had and what I could do my best to bring to the attention of other developers.

The book is language-agnostic and provides ideas that developers should keep in mind when doing their development - clear variable names, making comments that make sense, refactoring tips and hints for implementing your ideas in code. He recommends the book to any developer (in any language) to help them make code that will stand the test of time and be easier to manage/understand in the future.

The OAuth protocol is a fantastic way to login to remote services and websites. Unfortunately the spec is different in OAuth 1.0 and the yet un-solidified 2.0, the implementation is also different across different services. At the moment this is a bit of a goose chase, but libraries like li3_oauth can help! [...] I like to be in control and calling the shots! I also want to have users have the option to login to other services under the same umbrella. Working directly with OAuth is what I wanted to do. Of course I was doing this in Lithium because it is clearly the best PHP Framework!

His process is broken up into four steps:

• Grab the latest version of the li3_oauth plugin
• Fork and refactor the plugin
• Create the Tweet and Facebook controllers
• Refactor a bit more to turn it into a service

The code changes are pretty minimal and are included in the post.

In fact, it is the advised best practice for controllers in shared bundles. When you do, you will no longer have access to these useful methods, in this post I am going to look at how to accomplish the same tasks without them. I have created a simple controller for some basic form interaction with a model which uses the base controllers methods. I am going to go through how to change this to a service which does not extend the base controller.

He starts with his "TestimonialController" that does some of the basic CRUD operations on the testimonial information. He shows you, step-by-step, the refactoring needed to stop using things like the default controller helpers (each with replacement code). With those removed, he can move to extend "ContainerAware" instead of "Controller", make the controller a service and doing some dependency injection for needed resources.

Working on a symfony app, you usually have a mix of domain objects that are used by symfony actions, interspersed with symfony specific code such as logging and sfContext type stuff. A common bad practice I see is symfony specific code peppered inside of domain objects that could be used elsewhere (such as inside of a Zend app or a script from the cli) but now can't as they're coupled to the symfony code. One way you can remove an unwanted dependency is to use the Observer pattern - the dependency is pushed from inside the subject object to the client code that initialises the subject.

He sets up a scenario where a symfony action hits a web service and there's a dependency on two other types of objects (a service and transport object). He starts with the code for this method and gradually refactors out those two dependencies, removing an sfContext call from inside the service client and adds attach/detach/notify methods to implement the SplObserver on the class.

Working heavily with the Symfony2 Dependency Injection Container, I feel that we found some typical refactorings towards a DI container that emerge during the introduction of such a component. I want to write down the preliminary results of trying to systematize more or less as a draft. I will use the Symfony2 DI container configuration as an example but most of the refactorings should be applicable to other containers as well, some of them even to dependency injection without a container.

He's broken it up into a few different sections:

• Making a dependency explicit
• Introducing interface injection
• Exposing the service

I have a legacy application which was originally written in straight PHP with a few classes that I have created for convenience, but this is old and I am wanting to get this into a modern web framework. [...] I wanted to update my site with better validations anyway so I will start with flash messages and then validations. For flash messages in lithium you will need the li3_flash_message plugin.

He works through the different parts of the framework setup he needed including a simple bootstrap file and configuring it to use the li_flash_message library. He shows how to use validation rules on submitted data to ensure things like email an link format validity as well as spit back a message for any that are incorrect.

What should you do to make sure new code works properly when you're refactoring old code? I asked myself this question recently, when I needed to refactor a big bunch of procedural PHP code into a neat, testable, OOP-style interface. The conclusion I came into is that you should write unit tests - not to test the old code, but as requirements for the new code.

He suggests setting up a system where unit tests are set up to be where the requests are recorded - a sort of reverse TDD since you already have code to work with. Even if all of the tests aren't 100% implemented, at least you can run them and see what features you have left to do.

When discussing books on software engineering with colleagues, I got the idea of listing the best books I've read in the past 15 years. Because it seems useful, but also because that will allow others to tell me which ones I should have read.

He lists five books that cover some of the "meta" about programming:

• Applying UML patterns
• Design Patterns - GoF
• Refactoring (Martin Fowler)
• Test-Driven Development (Kent Beck)
• Clean Code (Robert Martin)

When you look at the list of changes for PHPUnit 3.5, you will see that many of them deal with refactoring to components. Here is an overview of these new components.

Components that were refactored to work even better include:

• PHP_CodeCoverage
• DbUnit
• PHPUnit_Selenium
• PUPUnit_MockObject