Practical PHP Refactoring: Duplicate Observed Data

In the scenario of today, we have informations of some kind which are present in the view (script, variables, presentational objects, JSON) but not in the domain objects. This kind of data must be computed starting from the domain objects of course, but this logic may grow and is not always consistent with presentational purposes.

For example, formatting a number is a presentational operation, no matter how complex are the rules; but arithmetic operations are usually a responsibilities of the domain objects as their result represents a domain concept (a tax; a discount; a total price).

The more the rules for updating become complicated, the more they should be pushed into the domain layer instead of residing in the upper ones. With domain concepts like discounts and taxes, they will get more complex over time.

The Duplicate Observed Data refactoring means that information, being represented by one or more fields or objects, find its place also in the domain layer. The presentation layer then just duplicates the information and massages it for displaying, or filter it when it comes as an input.

Not really an Observer

If you know the Don't Repeat Yourself maxim, you also know that everything that is duplicated must be kept in sync. In the original intent, an Observer pattern must be setup between the domain objects and the presentation layer; but in the original intent, this refactoring targets desktop applications.

In the PHP case, the situation is a lot different: objects are transient and views are generated at each request. Even when we get to store objects between requests in the session or with an ORM, the presentational objects are continuously rebuilt from scratch. The JavaScript side may take advantage of the original Observer-based refactoring, but this is the Practical PHP Patterns and we will see a PHP version.

Since there is no persistent view object for us, it suffices to move the fields in the domain object and copy their values in a readable form during display, just as we do already with other fields. Of course, it will be the other way around when receiving an input or requests for state change: the field must be handled by the presentation layer and passed to domain objects when its modification is supported.

Steps

The PHP-version steps are different from the classic ones described by Fowler. 

1. Introduce some duplicated fields in the domain classes, mimicking the ones already existent in the presentation.
2. Copy the logic for their computation in the domain classes; you may test this logic at the unit level, and it will be even simpler now that the results are uncluttered by formatting, JSON encoding, or HTML tags.
3. Substitute logic with a copying operation in the presentational classes; copying should already be in place for most of the data, so it's just a matter of doing more of it. You may have to introduce getters or equivalent methods on the domain classes.

Example

In the initial state, the invoice total is computed as part of the view object. We want to move the logic into the domain object and encapsulate the calculation there, since it will get more complex in the future. The view will continue to build an output from the available fields, which is better suited to its responsibilities.

<?php
class DuplicateObservedData extends PHPUnit_Framework_TestCase
{
    public function testTheTotalMustBeDisplayed()
    {
        $invoice = new Invoice();
        $invoice->addRow(100);
        $invoice->addRow(50);
        $invoiceView = new InvoiceView($invoice);
        // simplified representation to avoid cluttering this example with HTML
        $this->assertEquals("100\n50\n---\n150", $invoiceView->__toString());
    }
}

class Invoice
{
    private $rows = array();

    public function addRow($amount)
    {
        $this->rows[] = $amount;
    }

    public function getRows()
    {
        return $this->rows;
    }
}

class InvoiceView
{
    private $rows;

    public function __construct(Invoice $invoice)
    {
        $this->rows = $invoice->getRows();
    }

    public function __toString()
    {
        return implode("\n", $this->rows)
             . "\n---\n"
             . array_sum($this->rows);
    }
}

We duplicate the logic for a short time, adding a getter exposing the data (total as the sum of all the rows) on the Invoice domain object. The data may be a field which is updated after each relevant event or a getter that calculates the current value.

class Invoice
{
    private $rows = array();

    public function addRow($amount)
    {
        $this->rows[] = $amount;
    }

    public function getRows()
    {
        return $this->rows;
    }

    public function getTotal()
    {
        return array_sum($this->rows);
    }
}

Now we can substitute the calculation logic in the presentation layer (an oxymoron) with a duplication of domain data.

class InvoiceView
{
    private $rows;
    private $total;

    public function __construct(Invoice $invoice)
    {
        $this->rows = $invoice->getRows();
        $this->total = $invoice->getTotal();
    }

    public function __toString()
    {
        return implode("\n", $this->rows)
             . "\n---\n"
             . $this->total;
    }
}