Practical PHP Refactoring: Extract Subclass

So far, we have only treated the movement of object members (fields and methods, and constructor as special methods); the assumption we made was that these members are moved between classes in an hierarchy which already exist.

Larger scale refactorings involve modifying the hierarchy itself by adding and removing classes. In the scenario of today, a set of members (either methods or fields) is used only in some instances of a class. The proposed solution is to extract a subclass where those members can be moved.

What a subclass represent

You can think of classes, in mathematical terms, as precisely defined set (the ordinary, non-fuzzy one). A class represents a set of all its instances (it is actually isomorphic... let's just say it like that).

A subclass represents a subset of the original set, so only some instances of the superclass will be also instances of the subclass.

In most programming languages, subclasses of a given class are disjunct sets, but they may not cover the whole original set unless the superclass is abstract.

In any case, a characteristic that applies only to some instances indicates an unexpressed subset, and we can extract a subclass to represent it.

Moreover, all the instances not in the subset (instances of the superclass but not of the subclass) will be simplified as their code will not comprehend methods and fields which are not necessary.

Steps

1. Define a subclass of the original one with the extends keyword.
2. Split the original constructor if needed: the initialization of fields that are only in the subclass must be in the subclass constructor, so that they are not required to instantiate the superclass.
3. Replace calls to the constructor, which are usually new operators but also static Factory Methods. Separating business from construction logic helps here as all your instantiations will be in creational objects like Factories and Builders.
4. Now that all client code already refers to the right instances, use Push Down Method and Push Down Field on all the members only interesting for the subclass
5. The tests should pass.

Since this refactoring involves modyfing the hierarchy and the client code that deals with instantiation, you should execute the whole test suite.

An additional step is suggested by Fowler: there could be some fields that represent information now carried by the hierarchy (e.g. a type code). These data can be the target of and become fixed into the hierarchy: for example you can substitute a $itemType field with a itemType() method which returns a constant string, and that is redefined in the subclass.

Example

We start from a single class, NewsFeedItem, representing an item in a list of updates shared in a social network.

<?php
class ExtractSubclass extends PHPUnit_Framework_TestCase
{
    public function testAPostShowsItsAuthor()
    {
        $post = new NewsFeedItem("Hello, world!", "giorgiosironi");
        $this->assertEquals("Hello, world! -- @giorgiosironi",
                            $post->__toString());
    }

    public function testALinkShowsItsAuthor()
    {
        $link = new NewsFeedItem("/posts/php-refactoring", "giorgiosironi");
        $this->assertEquals("<a href=\"/posts/php-refactoring\">/posts/php-refactoring</a> -- @giorgiosironi",
                            $link->toHtml());
    }
}

class NewsFeedItem
{
    protected $content;
    protected $author;

    public function __construct($content, $author)
    {
        $this->content = $content;
        $this->author = '@' . ltrim($author, '@');
    }

    /**
     * @return string   an HTML printable version
     */
    public function __toString()
    {
        return "$this->content -- $this->author";
    }

    public function toHtml()
    {
        return "<a href=\"$this->content\">$this->content</a> -- $this->author";
    }
}

We notice there are two patterns of usage, described by the tests:

• instances representing text.
• Instances representing a link.

Moreover, the toHtml() method is used only by those instances which model links, as text is enough for ordinary object. We can extract a subclass, Link. Let's define it:

class Link extends NewsFeedItem
{
}

We replace the instantiations in client code where needed; in this example this code is represented by the tests:

<?php
class ExtractSubclass extends PHPUnit_Framework_TestCase
{
    public function testAPostShowsItsAuthor()
    {
        $post = new NewsFeedItem("Hello, world!", "giorgiosironi");
        $this->assertEquals("Hello, world! -- @giorgiosironi",
                            $post->__toString());
    }

    public function testALinkShowsItsAuthor()
    {
        $link = new Link("/posts/php-refactoring", "giorgiosironi");
        $this->assertEquals("<a href=\"/posts/php-refactoring\">/posts/php-refactoring</a> -- @giorgiosironi",
                            $link->toHtml());
    }
}

We execute Push Down Method on toHtml(), which is only called for Link objects. There are no other members to move.

class NewsFeedItem
{
    protected $content;
    protected $author;

    public function __construct($content, $author)
    {
        $this->content = $content;
        $this->author = '@' . ltrim($author, '@');
    }

    /**
     * @return string   an HTML printable version
     */
    public function __toString()
    {
        return "$this->content -- $this->author";
    }
}

class Link extends NewsFeedItem
{
    public function toHtml()
    {
        return "<a href=\"$this->content\">$this->content</a> -- $this->author";
    }
}

An additional step could be to redefine the constructor to provide a more precise API, calling the first field $url or $path instead of $content.