On the Web-Techno.net site there's a new tutorial posted that talks about the DRY principle in development (Don't Repeat Yourself) and why you might be misunderstanding the intent.

I know what you are thinking: "Again a boring article on DRY? Don't we have enough already?". You might be right. However I see too many developers (junior or senior) applying DRY like they are doing some witch hunting. Totally randomly or everywhere they can. So apparently we never have enough DRY principle articles on Internet.

A little reminder for those in the back who don't follow: the DRY principle means "Don't Repeat Yourself" and was first introduced in the The Pragmatic Programmer. The principle itself was known and applied before this book came to life. However the Pragmatic Programmer defined it precisely and put a name on it.

He starts by defining the original intent of the principle: not repeating knowledge (not necessarily repeating code). He gives an example of a e-commerce site and the logic around "shipments". If there's logic around these shipments happening in multiple places in the application, that can lead to maintenance issues down the line. He suggests creating a single instance of the knowledge about shipment handling rather than just reducing code duplication. He gives an example of a product instance and code duplication happening in some of the data validation. After showing a possible solution for this particular issue he gets into some issues that come from over-DRYing your code including useless abstractions and premature optimization.

On the QaFoo site they've shared a post with a helpful refactoring matrix that can help you determine the best approach to handling changes to your legacy code.

When you are beginning to consider refactoring your big legacy codebase towards a new software design, then it is not uncommon to feel helpless after estimating this to be a huge terrifying 2-5 years project.

To help solve the problem of not knowing where and how to begin, we have had great success using a decision matrix to decide how each part of the legacy code should be changed in such a refactoring project.

They start with the two main factors that should influence your decisions: the rate of code change and business value of the code. This builds out the matrix and the best way forward for each option. They go through the four approaches, what they would involve and how it relates back to the rate of change/business value factors. The post ends with links to a few other articles pointing you in the right direction for starting the refactoring process.

Eric Hogue has a recent post to his blog looking at one of the more tricky aspects of the latest versions of PHP (the 5.3.x series) - late static binding. In a nutshell, late static binding (LSB) lets static classes and methods work more correctly than before. Eric gets into a bit more detail than that:

It came out almost 2 years ago, but it to me that many programmers around me have no idea about it. Myself, I have learned about it around 6 months ago. The PHP documentation defines late static binding as a way to "reference the called class in a context of static inheritance." This definition didn't really help me the first time I read it. Fortunately, there are more explanations in the documentation, and there are good examples. If you haven't, you should read it.

To clarify, he includes a code snippet showing the use of the "static" keyword to correctly reference a static method. He also includes in interesting bit about when's a good time to use it.

Recently, Pádraic Brady had to explain some of the design patterns, specifically the Factory and Abstract Factory patterns, to someone (or a group of someones) in his day to day business. To help make it easier for other people out there looking for the same information, he's posted what he said on his blog today.

First, he talks about the Factory pattern:

At some point in developing, developers will discover a need to support switching among various methods of performing an action. The example I used in a forum post earlier was Database Abstraction. Say for a moment you want to separate all the logic needed to create an Abstraction object (say using ADOdb Lite) into a central place for easier control. At this point the Factory Pattern starts rearing its head.

Of course, a bit of sample code is given to illustrate the point, creating the instance of an ADOdb object.

Next up is the Abstract Factory pattern - the difference being that these make it easy to switch between Factories using different resource (such as his example to switch between ADODB and PDO).

In these cases, we will have multiple Factories. However instead of one generically named Factory, we will have several specific Factories. This should (eventually) lead us to impose a parent class, which will allow duplicated code from each specific DatabaseAbstractionFactory to be moved up to the common parent class.

Just as before, they provide example code to illustrate the use of this slightly different pattern.

Recently, Pádraic Brady had to explain some of the design patterns, specifically the Factory and Abstract Factory patterns, to someone (or a group of someones) in his day to day business. To help make it easier for other people out there looking for the same information, he's posted what he said on his blog today.

First, he talks about the Factory pattern:

At some point in developing, developers will discover a need to support switching among various methods of performing an action. The example I used in a forum post earlier was Database Abstraction. Say for a moment you want to separate all the logic needed to create an Abstraction object (say using ADOdb Lite) into a central place for easier control. At this point the Factory Pattern starts rearing its head.

Of course, a bit of sample code is given to illustrate the point, creating the instance of an ADOdb object.

Next up is the Abstract Factory pattern - the difference being that these make it easy to switch between Factories using different resource (such as his example to switch between ADODB and PDO).

In these cases, we will have multiple Factories. However instead of one generically named Factory, we will have several specific Factories. This should (eventually) lead us to impose a parent class, which will allow duplicated code from each specific DatabaseAbstractionFactory to be moved up to the common parent class.

Just as before, they provide example code to illustrate the use of this slightly different pattern.