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.

In fact I think that using inheritance all the time is a very big mistake and makes your code hard to maintain and more hard to integrate (the latter is a mistake for application codes and a fatal mistake for libraries). The main problem with inheritance is that if you use it for coupling two classes, then a very important property of the subclass is used up: it's superclass. It is taken, reserved, and it can not be used for anything else furthermore. If you want to connect your subclass to an other class using inheritance, you can't.

He recommends avoiding the typical uses of typical superclass/subclass inheritance unless what you're doing specifically requires it. Working with interfaces, abstract classes and good composition planning is a much better idea.

Both solutions allow to instantiate an anonymous object with properties. They are used as value objects and have no other purpose than storing values, so no logic can be included and they don't come with methods. They can be used as function parameters instead of arrays, for instance. PHP 5.3.0 introduced anonymous functions and closures, so it is now possible to attach functions to these VOs (*). [...] The first thing to notice is that these properties are not methods but callable functions:

In his example, an anonymous function dynamically appended to an object doesn't have access to a property set on the object just one line before. There's a way around it with call_user_func, but it's not practical. His proposed solution is to create a type of Anonymous class that uses the __call method to catch the methods and translate them into calls to call_user_func_array automatically.

Already, there is talk of how, and if, to leverage PHP 5's object handling now that we don't need to deal with the weirdness of PHP 4's object model. Of course, because it's Drupal, our army of performance czars want to know just what the cost is for object handling, and especially advanced object magic like __get(), __call(), the ArrayAccess interface, and so forth.

He an his tests on a Thinkpad (Intel Core2 Duo 2.2Ghz) running Kubuntu and PHP 5.2.3. They were run two million times benchmarking the different methods for:

• function calls
• __call
• __get
• __set
• iterators (array)
• inheritance
• composition

His results are listed at the end of the post.

From the original comments made by Bernard Sumption:

All of the pain caused by inheritance can be traced back to the fact that inheritance forces 'is-a' rather than 'has-a' relationships. If class R2Unit extends Droid, then a R2Unit is-a Droid. If class Jedi contains an instance variable of type Lightsabre, then a Jedi has-a Lightsabre.

Travis agrees and then comes back with his second post to clarify something - composition versus inheritance:

I approach OOP from a flexibility standpoint with one of its biggest flex-points being loose coupling which in turn promotes reusability. I'm going to use Event as a hypothetical example.

He uses Events and design pattern illustrations (like the Visitor and Observer) to help illustrate his point.

Following on from my posts "Object-Oriented Concepts" and "Object-Oriented Javascript", I'm going to take a look at OOP in PHP.

In "Part 1: Definition" we took a look at defining objects and classes in PHP. In part 2 I'm going to look at the most important part of any object-oriented system - the relationships.

They look at inheritance, association, aggregation, and references. Code examples are sprinkled liberally to help illustrate the points.