When you first call new(), the database is searched to find out if the item exists. If it does, you receive a Product::Real. Otherwise, you receive a Product::Potential. This has the downside that the developer needs to test this in their code:

  my $god = Product->new('religion');

  if ( $god->exists ) {
      # Product::Real
  }
  else {
      # Product::Potential
  }
[download]

And no, Product::Real shouldn't call create() again, but since that method won't be defined in the base class, it's guaranteed to fail if called.

The benefit of this is that we use Perl's OO mechanisms to determine if we handle a method rather than this obvious, but clunky code:

  sub create {
      my $self = shift;
      if ( $self->exists ) {
          $self->croak('already exists');
      }
      # create the object
  }
[download]

Effectively, we're testing the type of the object from within the object and that's generally a design flaw. Separating the classes means that Perl does this for us.

However, this does mean that outside of the class, developers need to make at least one test of the object type (the 'exists' test) and this concerns me. I like to minimize procedural code as much as possible as it's a constant source of bugs.

Maybe I'm just being dense ... and I know it's kinda silly but for Product::Real ....

sub create {
  return shift;
}
[download]

sometimes you have to do some wild contortions if you painted yourself into a corner. So now you have the PaintedCorner pattern :-) (or is that an AntiPattern?)
-derby

Update: Hey ... no joking ... the OP may be an antipattern