I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 635 posts at DZone. You can read more from them at their website. View Full User Profile

Practical PHP Refactoring: Encapsulate Downcast (and Wrapping)

12.14.2011
| 4628 views |
  • submit to reddit

In statically typed languages, each variable must have a minimal type known at compile time. PHP instead, a is dynamic language where variable can contain any object, and the only enforcement of an interface can be performed on method parameters via type hinting.

Statically typed languages sometimes encounter the problem of downcasting: the compiler is only able to guarantee a basic type, and the object contained instead is an instance of a richer subtype. A Java example can be a collection of Object instances where some of them are actually a String: to obtain a String instance to be able to call string.startsWith("prefix_"), the code using the collection needs a down cast:

String myString = (String) myObject;

This problem was really diffused in old Java code (before Generics introduction) and still today in some cases.

What about PHP?

You'll never need to downcast objects: variables can contain handlers to objects or even scalars without compile-time checks. Casting with (ClassName) is not even supported by the language (while casting a non-object with (object) will give you a stdClass.)

Downcasting however means to promote a variable from a stricter interface to a richer one: we will apply this refactoring to scalars and their OO equivalents, Value Objects.

Note that in Fowler's book downcasting is applied only to objects: the same instance just aquires a new (larger) interface. Since this casting is absent in PHP and the type coincide with the current content of the variable, we will talk about conversions of variables to different types.

Scalars

First of all, you may need to cast scalar variables to other types (e.g. integer to boolean). PHP rules tell us how they are evaluated in its specification for type juggling.

Encapsulate Downcast is equally valid when we want to convert a type and only want to expose the right one. For example, we want to avoid this smelly code:

public function isASeatAvailable()
{
    return $this->numberOfSeats - 42; // 42 is a total of sold tickets
}
$result = (bool) $theater->isASeatAvailable();

The (bool) cast will be spread throughout all the client code calling $object. The logic of the refactoring is the same as for the casts on objects: encapsulating them into the method results in a cleaner API and the lack of duplication of the cast in all the client code.

Value Objects

Another form of casting/conversion that we need in hybrid languages like PHP is the conversion of a primitive (scalar or array) value into an object (Value Object usually).
Sometimes this conversion gets duplicated like for the case of casting primitives:

$topic = new Topic($object->getAllPosts());
$firstPage = new Topic($topic->getPart($offset = 0, $limit = 10));

A simple reason for why this happens in this little example is that the the Topic object, representing a collection of Posts, gets introduced into the codebase to host some new methods that make sense only on a set of Posts. However, it is not introduced in all the code, since it will take long for such a refactoring to be completed.

The result is that conversions to and from the primitive structure flourish; what we want to target with this refactoring is to encapsulate the initial conversions as much as possible, an only work with a closed algebra of objects in all the rest of the code:

/** @var Topic */ $topic = $object->getAllPosts();
/** @var Topic */ $firstPage = $topic->getPart(0, 10);
/** @var Topic */ $filteredTopic = $topic->getSelectedPostsForQuery("refactoring");

Docblocks

Docblocks applied to methods have also to be modified to reflect into the API documentation what you're returning (an object, a Traversable, an IteratorAggregate or a MyIterator). Thus this refactoring affects them.

While the @return information is embodied into the code in statically typed languages, PHP gives you freedom to return whichever type you need but does not provide a formal way to document the choices. The standard however, is the @return annotation:

/**
 * @return Traversable  containing strings
 */
public function threadTitles() { ... } 

Steps

The most important step in applying this refactoring is to identify the cases where it would work. There are many possible smells:

  • new MyClass(...) statements often executed on the result of a method.
  • Value Objects having many getters for their fields, or calculated fields, can often return another Value Object; look for duplicated logic on the client code.
  • Ultimately (the other way around), any method returning an array or scalar value is a suspect.

The second step is moving the down cast into the method. This mean modifying both the call and for objects, while you can do one step at the time in the case of scalar casting due to the (type) operation being idempotent.

Finally, remember to update the docblock of the modified methods accordingly.

Example

In the example, we target the most useful case: a Value Object whose creation from its primitive value should be encapsulated in a method.

This object models a license plate used in a Car. I just implemented the most basic case of advancement of a plate (it will overflow after 26 next() calls), to keep this code simple and to the point.

We see next() is the target of our refactoring.

<?php
class EncapsulateDowncast extends PHPUnit_Framework_TestCase
{
    public function test()
    {
        $plate = new Plate('AB123XY');
        $newPlate = new Plate($plate->next());
        $this->assertEquals(new Plate('AB123XZ'), $newPlate);
    }
}

class Plate
{
    private $value;

    public function __construct($value)
    {
        $this->value = $value;
    }

    /**
     * @return string
     */
    public function next()
    {
        // we're dealing just with the basic case
        $lastLetter = substr($this->value, -1);
        $lastLetter++;
        $nextValue = substr_replace($this->value, $lastLetter, -1);
        return $nextValue;
    }
}

In a single step we can keep the test passing. We modify what is expected by the client code, now a Plate instance:

<?php
class EncapsulateDowncast extends PHPUnit_Framework_TestCase
{
    public function test()
    {
        $plate = new Plate('AB123XY');
        $newPlate = $plate->next();
        $this->assertEquals(new Plate('AB123XZ'), $newPlate);
    }
}

We modify the docblock, in particular @return, and we perform the instantiation inside the method.

class Plate
{
    private $value;

    public function __construct($value)
    {
        $this->value = $value;
    }

    /**
     * @return Plate
     */
    public function next()
    {
        // we're dealing just with the basic case
        $lastLetter = substr($this->value, -1);
        $lastLetter++;
        $nextValue = substr_replace($this->value, $lastLetter, -1);
        return new self($nextValue);
    }
}
Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)