On PHPMaster.com today there's a new tutorial posted that wants to provide a guide to walk you through a trio of ideas to help with code/idea reuse in your applications - inheritance, composition and delegation.

The popular belief is that reusing implementation, thus producing DRYer code, boils down to exploiting the benefits that Inheritance provides, right? Well, I wish it was that easy! [...] If you don't know what path to travel when it comes to reusing implementation, in this article I'll be doing a humble walk-through on the Inheritance/Composition/Delegation trio in an attempt to showcase, side by side, some of their most appealing virtues and clunky drawbacks.

He starts off with a look at Inheritance, showing with a small code sample showing the creation of an interface and a resulting PDO adapter class implementing it. He also shows the concept of composition, following the ideas of the Adapter pattern. In his Delegation example he shows how to implement the creation of the connection object as a part of the class' creation.

Matthew Weier O'Phinney has a new post to his blog today showing you how to use action helpers to make widgets that you can reuse all over your Zend Framework application. His method doesn't use the "action()" helper, either.

The situation all started when Andries tweeted asking about what he considered some mis-behavior on the part of the action() view helper -- a situation that turned out not to be an issue, per se, but more a case of bad architecture within Zend Framework. [...] The helper was done this way because Zend Framework does not render views a single time -- it instead renders after each action, and accumulates views to render in the layout.

Instead, he offers action helpers as a solution. He gives an example of a user module that has views, helpers and forms but no controllers, including a Bootstrap file. This bootstrap defines the helpers, configuration file and adds the helpers into the process flow of the application. Once things are all set up and the action helper is created, adding the module to a page is as easy as calling "createProfileWidget()" into a partial view.

In a quick post to his blog Lukas Smith talks about the proposal for traits support that's been pending for PHP for a while now. Recent updates have been made to it, so it's come back up to the front of developer's minds:

Stefan has since tweaked the proposal and in the latest version it includes an alternative approach called Grafts along with the original Traits idea, which is essentially language level delegation pattern support. I am absolutely sure that we will either see Traits or Grafts in the next non patch release of PHP (aka 5.4 or 6.0).

Lukas would like to see the support go in sooner than later, so he requests some comments and thoughts on the proposed functionality and to leave them as comments on his blog entry.

Sebastian Bergmann has announced the release of the latest version of the popular PHP unit testing software - PHPUnit.

Among the features introduced in this new version, the most notable are the support for test dependencies and fixture reuse as well as the possibility to run tests in separate PHP processes for increased test isolation. Please have a look at the ChangeLog for a complete list of changes.

As a teaser, he also mentions the work being done on the code coverage features that will be included in the next release.

In this recent blog entry Jani Hartikainen looks at the creation of generic actions for Zend Framework applications - methods that can be used to help eliminate code duplication:

Sometimes you will need nearly the same functionality in many actions. [...] There are several ways to deal with this, such as moving the code into a separate function, or an action helper. But in this post, I'm going to introduce so called "generic actions" - parametrized, easy to reuse actions - which is an idea similar to django generic views.

His example takes a generic action - one that grabs and output records from a table - and modifies it to take in parameters from the defining function as to which action/controller/model and ID to use. Then this action can be used over and over in multiple places without having to do any copy and paste coding.

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.

In a recent entry to his blog Sean shows off a new specifications library he's created to replace common comparison functionality with a series of specs.

I thought I'd share a PHP library implementing this idea by Evans and Fowler. Written for PHP5, it's a library for defining custom specifications using composition and inheritance.

He gives the example of "Person" objects with name and age properties. A search might involve looking directly at the properties to location one that's, say, younger than 35 and has a last name of Johnson. His specification class replaces this and makes it more reusable by applying things like GreaterOrEqualSpecifications and EqualSpecifications to standardize the evaluation. Then its just a quick call to the isSatisfiedBy method to check for correctness.

Maarten Balliauw has made a new blog post today about a method he's using to help reuse some of the business logic that Excel spreadsheets can have in a PHP script with help from PHPExcel.

In many companies, business logic resides in Excel. This business logic is sometimes created by business analysts and sometimes by business users who want to automate parts of their everyday job using Excel. [...] Did you know you can use PHPExcel to take advantage of the Excel-based business logic without having to worry about duplicate business logic?

He creates a quick example of a script that can take in an Excal file and pull it into a PHPExcel object, ready for manipulation. He fills in values for the already defined fields (like "carColor" or "leatherSeats") and uses the getCalculatedValue method to perform the action on the cell. The output is dropped into a variable that can be echoed out or used later on in the PHP script.

The Developer Tutorials blog has an interesting perspective on the whole framework front today - use whatever framework you choose, but be sure to "add a little Zend" when you need it.

The Zend Framework is a fairly standard, (optionally) MVC PHP application framework. It comes with all the usual functionality; request routing, database access, templates (through view files) etc. [...] But here's the kicker: it works entirely standalone. The classes and their methods can, generally, be used statically in any context, or at least independently of the framework.

They point out that the components of the Zend Framework, while able to happily live in their self-contained MVC bubble, can also break "out of the box" and live their own happy, separate lives. He even points out another blog entry looking at using the Zend Framework right along side CodeIgniter in a web application.

Nick Halsted has posted the first two in a series of programming tips, not necessarily specific to PHP, but still very useful.

Over the years I have built up what I call my 'programming wisdom' this is what has replaced my early years of supposed 'raw talent'. [...] So I thought to myself what have I learnt that I can put across that will be useful to my fellow programmers who have not made all the mistakes I have. I plan on writing a long series of programming tips over the coming weeks (disturbed only by solicitors, investors and other scary programming time eating monsters).

The first two of the series are:

• Don't Repeat Yourself - make reusable code to save you time in the long run.
• Test, test, test - finding bugs in software before it's too late.