Question

I have a scenario where I have several classes that extend from a common ancestor because they all share common properties and methods. Half of these classes (Group A) contain a property that is not shared by the other half (Group B), so each class in Group A explicitly declares this property rather than the parent class.

e.g.

class parent
{

}

class child1 <and child2, and child3> extends parent
{
    protected $specialProperty;
}

class child4 <and child5, and child5> extends parent
{
    // no "$specialProperty"
}

I have some behavior I need to implement that acts on $specialProperty. Naturally, I’d like to put this in a parent class and do it only once, but $specialProperty doesn’t exist in all of the child classes.

One option is to create an intermediate, abstract class that declares $specialProperty and implements the required behavior, but I’m reluctant to do that for a few reasons:

1. This scenario is going to be coming up more soon. What do I do then? Create 5 or 6 different middlemen abstract classes for each of these functionalities?
2. The class hierarchy is already about 5 levels deep above parent. Should I really be creating more and more layers to make up for a less-than-ideal class hierarchy that was conceived hastefully with limited requirements?
3. At least as far as PHP is concerned, wouldn’t so many layers of inheritance eventually lead to performance issues?

Another option is to do the following:

class parent
{
    public function functionThatTheAppWillCallAutomatically()
    {
       if ( property_exists($this, 'specialProperty') )
       {
           // do stuff with specialProperty
       }
    }
}

The “stuff” would get executed by child classes that have $specialProperty and skipped by those that don’t. I hate this solution though because it just seems wrong and sloppy to me. In my opinion, the parent shouldn’t be deciding what to do based on the properties of the child (heck, it probably shouldn’t even know that the child exists – isn’t that the reason for the child class in the first place?)

In short, I’m not sure which of these two options is the least bad, or if there’s a better possibility. I’m anxiously awaiting suggestions.

Thanks!

---

EDIT:

I ended up doing the following to implement this specialized functionality.

class archivalDecorator extends decoratorBase /* decoratorBase just has constructor and the object property */
{
    public function archive()
    {
        if ( !$this->object->archive() )
        {
            return false;
        }

        if ( property_exists($this->object, 'specialProperty') )
        {
            // do extra stuff here that involves "specialProperty"
        }

        return true;
    }
}

This way, all of my objects perform the same archival workflow, but the classes that require special behavior can still perform it without me needing to implement dozens of subclasses in the hierarchy for these special cases.

Though I’m still using property_exists(...) to determine if the special behavior is needed or not, I think this is OK now because I’m not doing it from within the parent class. $specialProperty is a public property, so there’s no reason external classes shouldn’t know about it, but something just felt wrong about the parent class checking for that property in a child class using $this.

I hope I haven’t misapplied the concept.

Answer 1

It’s really hard to say without know what your classes are doing, but your issues (deep class hierarchies with multiple subtrees, optional cross-tree functionality, etc) are indicative of the need for some decorator pattern.