There is a design pattern that does what you want it to do. It's called a (I think) facade. The idea is that you have a bunch of layers over an object that will trap calls to a method and validate whatever. Once that actual object's method is called, it can assume the input data is good.

Somebody almost certainly has documented filters as a design pattern - but it's not a facade :-)

A facade is when you hide the details of using a group of objects behind a simple interface (e.g. LWP::Simple is a facade for LWP::UserAgent et al.)

There's an article on facade's in 0.4 edition of the Perl Review for those interested.

I have been doing some background reading on 'facades'. As far as I can work out facades are a way of combining previously unrelated objects. Out of interest, where do you think that this comes into what I have described? I am not saying you are wrong in your assertions. I would just like to understand your thinking behind them.

I think it was just dragonchild mis-remembering the name of the design pattern - what you're after isn't a facade.

Filters/Pipelines are such a common idiom I have to believe that somebody has documented it as a design pattern somewhere... possibly in a PLoP proceeding. However, I don't have an academic library available to check :-)

I think there's a little confusion because the terms "filtering" and "pipelining" are more often used for applying a series of transformations to something - rather than a series of predicates that exclude objects. From your post I think you're after the latter.

A more concrete example of what you, in particular, are attempting would help. As somebody else already pointed out grep does what you want in simple cases.

If you need to build objects that can apply specific filters, something like this:

#! /usr/bin/perl

package Sieve;
use strict;
use warnings;

sub new { bless [], shift };

sub add_predicate {
    my $self = shift;
    push @$self, shift;
}

sub ok {
    my ($self, $item) = @_;
    $_->($item) || return(0) foreach @$self;
    return(1);
};

sub sieve {
    my $self = shift;
    grep {$self->ok($_)} @_;
};
[download]

allows you to do:

my $o = Sieve->new;
$o->add_predicate( sub { $_[0] > 5 } );
$o->add_predicate( sub { $_[0] % 2 } );

my @original = (1..15);
my @sieved = $o->sieve( @original );
print "original: @original\n";
print "odd numbers > 5 are: @sieved\n";

__END__
producing

original: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
odd numbers > 5 are: 7 9 11 13 15
[download]

If you need more - you'll have to give up a bit more detail ;-)

I am interested in using Facade methods. There is a Perl class called 'Facade'.

NAME
    Class::Facade - interface to one or more delegates
[download]

Does anyone have examples of where they have used this class for the purpose previously described? I have read through the documentation. However, it is not easy for me to understand.

Forget XML. XML doesn't exist for your solution. You are NOT using XML.

You are asking how to serialize objects. There are a million solutions for that, from Object-Oriented databases to solutions in C++, Java, and Perl.

In Perl, a quick'n'dirty solution could use Storable to serialize the object and store the serialized string.

Better would be to have the object know how to serialize itself, possibly depending on Storable to do the actual dirty work. (Some modules, like DBI, don't store well.)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.