Read the description of the Builder Pattern in the Design Patterns book. This should do what you want.

Basically:

• Each Matrix HAS-A CellRenderer (the Builder object)
• There is an abstract CellRenderer class that defines the interface: render_scalar(), render_link(), render_percentage() ...
• Concrete CellRenderer classes like HTMLCellRenderer, ExcelCellRenderer, etc., implement the interface of the CellRenderer class.
• Now you can configure a Matrix with a CellRenderer for the appropriate output type.
• The Matrix knows which of the CellRenderer interface operations to call for which type of cell item (switch statement).

Alternatively, and much cooler, you can solve this problem in the CLOS (Common Lisp Object System) way by using Damian Conway's module Class::Multimethod. This module allows you to have dynamic dispatching based on the type of multiple arguments.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Can you explain in more detail, or sketch a toy example?

How 'bout:

#!/usr/bin/perl -w

### set up some packages
### this would normally be done using their own files
{
  package Nifty;
  sub new {
    my $type = shift;
    my $self = {@_};
    if( $self->{type} ){
#     require $self->{type}; # if the Nifty::A packages
      # were in their own files
      $type = $self->{type};
    }
    return bless( $self, $type);
  }

  sub get {
    return "Some_Value";
  }
  ### default print method
  sub print_it {
    my $self = shift;
    my $str  = shift;
    return $str;
  }
}

{
  package Nifty::A;
  @Nifty::A::ISA = qw(Nifty);
  sub print_it {
    my $self = shift;
    my $str  = shift;
    return "<a href=$str>$str</a>";
  }
}

{
  package Nifty::B;
  @Nifty::B::ISA = qw(Nifty);
  sub print_it {
    my $self = shift;
    my $str  = shift;
    return uc($str);
  }
}

# more types et cetera

### here is the main program
use strict;

my ($obj,$val);

$obj = Nifty->new();
$val = $obj->get();
print $obj->print_it( $val ) ,"\n";

$obj = Nifty->new(type=>'Nifty::A');
$val = $obj->get();
print $obj->print_it( $val ) ,"\n";

$obj = Nifty->new(type=>'Nifty::B');
$val = $obj->get();
print $obj->print_it( $val ) ,"\n";

exit;
[download]



Basically, put the normal functionality in the base class. Anything that changes, put in the sub classes.

my @a=qw(random brilliant braindead); print $a[rand(@a)];

The better way is to define one output function for each type, with a parameter (a constant) of the method of output that you are generating; it's up to the individual type if it needs to heed that type, with a default output of "plain text". This way, adding a new output type won't break anything to start, and you can then work back to update those types of objects that will work with that data type to do so; those that are unaffected like scalars need no additional updating.