www.greg-wright.co.uk

I've been working on a system that takes different types of things in an order. The order system is split up by the type of the thing beng ordered, which isn't very clever but historically that's the way someone wrote it so we just have to live with it, refactoring the code and data is not an option.

In modelling the data for the differnet types of thing being ordered it turns out to be useful to have an empty abstract class:

abstract class AbstractOrderItem implements Model {
// Add a constructor to initialise the model
}

Now order items extend AbstractOrderItem:

class CarOrderItem extends AbstractOrderItem ...
class PlaneOrderItem extends AbstractOrderItem ...
class TrainOrderItem extends AbstractOrderItem ...

Now it you want to handle a list of OrderItems that's fine:

    function paintBlue(AbstractOrderItem $item) {
      $item->color='blue';
      $item->save();
    }
  

So if the Order class implements the Iterator interface you can do this:

function ColorMyOrder(Order $order) {
  foreach($order as $orderItem) {
    $this->paintBlue($orderItem);
  }
}

Note that without the intermediate abstract OrderItem class the code in ColorMyOrder would have to take Model instances so the programmer could pass in any old Model Instances like users, credit cards etc. which would be potentially disasterous.

Of course it would be nicer to define a setColor() method in the AbstractOrderItem class or to make the AbstractOrderItems sign up to being Colourable (implementing an IColorable interface) but this seems to be a reasonable if imperfect half-way house.