Aggregate pattern

Members of a common subclass are each known to have certain methods. These methods return information about the state of that perticular object. It does happen that an application is concerned with an aggregation, or amalgamation, of data from several object of the same type. This leads to code being repeated around the program:

  my $subtotal;
  foreach my $item (@cart) {
    $subtotal += $item->query_price();
  }

  my $weight;
  foreach my $item (@cart) {
    $weight += $item->query_weight();
  }

  # and so on

Representing individual objects when the application is concerned about the general state of several objects is an ImpedenceMismatch. This is a common mismatch as programmers feel obligated to model the world in minute detail then are pressed with the problem of giving it all a high level interface.

Create an object as a wrapper[?], using the same API, with a common subtype as a cart entry, but allow it to hold other objects of that subtype: make it a container. Define its accessors to return aggregate information on the objects it contains.

  package Cart::Basket;

  @ISA = qw(Cart::Item);

  sub query_price {
    my $self = shift;
    my $contents = $self->{contents};
    foreach my $item (@$contents) {
    }
  }

  # other query_ routines here...

  sub add_item {
    my $self = shift;
    my $contents = $self->{contents};
    my $item = shift; $item->isa('Cart::Item') or die;
    push @$contents, $item;
    return 1;
  }

The aggregation logic, in this case, totalling, need only exist in this container, rather than being strewn around the entire program. Less code, less CodeMomentum, fewer depencies, more flexibility.

We have an object of base type //Cart::Item// that itself holds other //Cart::Item// objects. That makes us recursive and nestable - one basket could hold several items along with another basket, into which other items and baskets could be placed. You may or may not want to do this intentionally, but to someone casually calling //->query_price()// on your //Cart::Basket// object won't have to concern himself with this - things will just work.

This will break. Unless the advice of AbstractRootClasses is followed and different implementations of the same thing share the same interface, the basket can't confidently aggregate things. Unless the advice of StateVsClass is heeded, AbstractRootClasses will never be acheived: the temptation to draw distinctions between classes that lack certian functions will be too strong. These distinctions run counter to AbstractRootClasses, causing segmentation and proliferation of interfaces for no good reason. This proliferation of types prevents aggregation in baskets and containers. Avoid this vicious cycle. Parrots that don't squak are still parrots.

XXX IteratorInterface blurb - aggregation is kind of like iteration in that they both present information gleaned from a number of objects through a tidy interface in one object. While IteratorInterface deals with each contained or known object in turn, AggregatePattern summerizes them in one fell swoop.

The article is originally from Perl Design Patterns Book.

• Visitor pattern
• Template class[?]
• Facade pattern
• Iterator interface[?]
• Type safety[?]
• Functional programming
• State vs class[?]
• Iterator interface[?]