Matthias Nobak has continued his series of posts covering software architecture and class structure. In a previous article he talked about using interfaces and in this latest tutorial he covers the reuse of "domain code", the main logic of your application (rather than the structure).

Last week I wrote about when to add an interface to a class. The article finishes with the claim that classes from the application's domain don't usually need an interface. The reason is that domain code isn't going to be swapped out with something else. This code is the result of careful modelling work that's done based on the business domain that you work with. And even if you'd work on, say, two financial software projects in a row, you'll find that the models you produce for each of them will be different in many subtle (if not radical) ways. Paradoxically you'll find that in practice a domain model can sometimes be reused after all. There are some great examples out there. In this article I explain different scenarios of where and how reuse could work.

He then goes on to cover three "reuse" situations, providing a summary for each:

• Reuse-in-the-small
• Reuse-in-the-large and software diversity
• Reuse-in-the-even-larger: reusing entire subdomains

He finishes up the article sharing some thoughts about which of the types seems more obtainable and, in his experience, useful.

On the Zend Developer Zone there's a new post talking about scheduling in applications ("scheduling elePHPants") including both library recommendations and advice about code reuse.

It was while I was creating the 100th or so cronjob to do some very similar to the other 99 that I thought, “Hey! Why not just put all this in a database and check it once a minute instead?” [...] It would be so much easier to deal with in PHP. Also, cron does not scale well at all either in performance or management.

The problem is that cron is an elegant solution for “Do this at that time” type of problems. Every solution I came up with was basically re-creating cron. That in itself isn’t a bad thing, but the logic involved in doing what cron does is mind-melting.

[...] Then it hit me, I am probably not the first person that has had this need. There have probably been other people who needed to implement “Do this at that time” within a PHP application. So I started looking around. What I found was encouraging.

The author then mentions several packages that he went through searching for the right solution to his problem, noting that while Laravel-based solutions seemed nice, they wouldn't work with his framework choice (Slim). He decided on the cron-expression package, finding it to be the best fit for the project's needs.

I had spent countless hours trying to create the solution myself. [...] I got so lost in solving the problem, I forgot to look to see if someone had already solved it. [...] After I finally came to my senses, I tweeted that out to remind myself to “Use the Source”.

On the Qafoo blog today Kore Nordmann has a new post talking about code reuse through inheritance. He talks about base classes, sharing code and abstraction.

To me, inheritance has two properties: Defining an is-a relationship [and] making it possible to share code between classes by extending from a common base class. The is-a relationship between classes is one thing I like to use inheritance for. [...] The other thing you can use inheritance for is to share code between multiple classes. [...] I personally think that the latter is one of the worst things you can do in object oriented design. Bear with me for a moment and let me try to explain why I think that.

His example of doing it the wrong way is using the Active Record design pattern and how it's usually implemented - storage logic in the base class and business/table logic in the extending class. He then gets into an example that's a bit "smaller" creating diff display functionality and how the "code reuse by inheritance" creeps in a lot in helper methods. He also briefly looks at testing (or not testing) private methods and and the "Depth of Inheritance Tree" metric's recommended value.

For those that might have heard of traits (made available in newer versions of PHP, 5.4+) but haven't seen much of a practical application, this new post from Matthew Setter could help.

Here’s the situation which prompted the use of them, in a nutshell. I had a custom view helper which performed some rather elementary date & time formatting, based purely on US standards. When I first wrote the ViewHelper, I wasn’t aware of any other use case I’d have for it. So it made sense for it to be self-contained. Such is life however, as later in development the need did arise to do more date/time formatting. But this time, far removed from the view layer in a model. [...] So I weighed up my options and chose to go with Traits. I’ll be honest, there was the new & cool factor to them as well – as well as an irresistible sense of simplicity in them.

He shares the actual trait code he implemented, making two simple methods - one for formatting date and another for formatting the time - for his views to use. He also includes examples of it in use. He also sought some feedback

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.