I currently use a very simple set of core objects within my model layer: entities, mappers and service objects. [...] I dislike the phrase "service object" as the word "service" means so many things to so many people. I haven't heard a better phrase yet that everyone understands though.

He defines each of the types of objects to help make the separation clearer. Here they are in brief:

• Entities are objects that represent something in my business logic.
• Mappers know how to save and load an entity from the data store.
• Service objects provide the API that the rest of the application uses.

Some of the comments on the post relate his choices to use in Zend Framework v2-based applications, noting that there are some base components you can extend to create these kinds of objects.

What about code readability, from my point of view is one of the most important thing in the code. Who writes code that is easy to read, writes good code. Probably reading code is where you spent most part of your time, and not only your code, probably code of your team mates, or maybe code from the open source community, so write code that is simple and is easy to understand it's really important.

His tips (seven of them) are:

• Comment before write your code (DocBlock)
• Return frequently, Return early
• Break, Continue
• Code Standard / Name conventions
• Throw Exception
• Comment often, but not write stupid comments
• Methods can be always smaller than they are

It's a little difficult to read as the English isn't the speaker's native tongue, but it gets the point across. He also recommends reading this if you'd like more information about writing better OOP code that's easier to read.

I've been working on a Zend Framework 2 module within a larger project that doesn't have that many PHP class files. Specifically, it has a controller, a mapper, an entity, a service and a form. As a result, the traditional Zend Framework 2 directory structure for the Account module looks [overly complicated]. That's a lot of directories for not many files! As a result, I decided to flatten it to [something simpler].

He includes both the "before" and "after" directory structures and continues on with two more suggestions - the removal of the top level "Account" folder inside of "src/" and, finally, removing "src/" all together with a slight modification to the autoloading. With a simpler module, though, something like this might make it easier to maintain and "follow" later down the road.

• Todd Lombardo on user context
• Stefan Priebsch on data and persistence
• Patrick Allaert about data structures
• June Henriksen on the human side of programming

You can find out more about this issue (and go download your free copy) on the Web & PHP site. There's also seven previous issues, all free for download (PDF format)!

If you're not using interfaces in PHP, you are missing out on a powerful object-oriented programming feature. An interface defines how to interact with a class. By defining an interface and then implementing it, you can guarantee a "contract" for consumers of a class. Interfaces can be used across unrelated classes. And they become even more useful when combined with the new traits feature in PHP 5.4.

He illustrates with a package shipping example and uses an "Addressable" Interface to define the structure for both a Company and Users class. He includes code showing how to implement it in a more traditional "implements" way in a class, but also shows an interesting way to achieve the same thing with traits. Having a trait that follows the interface makes it easy to have a class adhere to the interface just by including the trait (or "using" it).

Very often I find myself writing input filters for large XML files using PHP. Common enough task; and PHP offer a great variety of tools to do this effectively depending on the situation. Unfortunately, almost as common is the lack of documentation for the aforementioned XML files. [...] I have looked around for a simple tool but I didn't really find a tool that gave me the quick and dirty overview I wanted. A year or so ago I finally wrote a small PHP class to analyze large XML files.

He includes an example XML file, the HTML output of the parsing and a sample of how to use the class to parse and output the XML structure, complete with some CSS.

The Pear Structures_Graph package allows creating and manipulating graph data structures. It allows building of either directed or undirected graphs, with data and metadata stored in nodes. The library provides functions for graph traversing as well as for characteristic extraction from the graph topology.

After sharing the one-line install, he shows how to create some instances of the package's Nodes and how to connect them to a graph and link them to other nodes. He includes a few examples - a simpler one with multiple nodes joined in a directed graph, another showing how to associate data with a node and how to query the graph for node connections and testing to see if the graph is acyclic.

As Drupal is in the process of considering how to restructure code to best leverage the PSR-0 standard, I figured it would be wise to take a quick survey of how some other major projects organize their code bases. This is not a complete rundown of every project, simply roughly comparable notes for those areas Drupal is currently discussing. I am posting it here in the hopes that it will be useful to more than just Drupal.

The projects he looked to for his examples were:

• CakePHP
• Symfony2
• Silex
• CodeIgniter
• Zend Framework 2
• Composer

For Abstact keyword we can say that, abstract is type of the class and class which we can't create a object of it. Surprised???? [...] Abstract class can be used some what like an interface in PHP. So basically we can implement class using abstract. We can't extend more than one abstract class while we can implement more than one interface.

They introduce you to the creation of an abstract class and show how to set up some abstract methods inside. These methods are required to be defined as a part of the extension in your class. One of the benefits they don't mention of abstract classes over interfaces is the ability to have methods in the abstract that are actual code, not just definitions of the structure (that's more of what interfaces are for).

I'm now going under the bonnet of our components, and looking at the different file roles that the PEAR installer expects to find when we distribute our component as a PEAR-compatible package. It isn't very often that a component needs to ship web pages too, but should the need arise, here's how to do it.

He starts by defining what a "web page" could be (HTML, Javascript, CSS, etc) and gives the place in the hierarchy they should fit. When you use the PEAR client to install the package, these files are placed in the "www" folder of your PEAR installation.