I was thinking about a design problem a co-worker has and my implementation idea seems reasonable, but strange. I'm sure there's a pattern or something which describes this, but I'd love feedback on the idea.
Imagine that you have "products". A product might exist, but it also might be a brand-new product being created (potential products). What I'm thinking is a factory 'Product' class. You start by creating the object:
my $whip = Product->new('whip');If we already have a 'whip' product, that returns a Product::Real class. Otherwise, it returns a Product::Potential class. Let's say it doesn't exist, we want to be able to do this:
$whip->create;At that point, it gets registered, stored in the database, and can get assigned to a client. It then reblesses itself into a Product::Real class. Attempting to call create() again is a fatal error because real products don't have that method, but you do gain a delete() method which unregisters the product and removes it from the database. The class then switches back to a Product::Potential instance.
Potential products actually have quite a bit of behavior unique to them, as do real products. I don't want one big fat class with a bunch of procedural if/else code to know if the product exists or not.
What is this design usually called (aside from 'stupid')? Basically, we have a factory class which instantiates subclasses which might mutate into another subclass depending on their state.
The idea sort of bugs me because the subclasses have significantly different behaviors and methods and silently transform themselves at runtime. Is there a better solution to this problem?
Cheers,
Ovid
New address of my CGI Course.
In reply to Reblessing yourself by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |