I constantly find myself prototyping objects to get a feel for the best way they should integrate into something I'm working on. Today, I had an odd little epiphany. Consider the following:
sub set {
my ($self, $uuid, $object) = @_;
$self->_cache($uuid, $object);
return $self;
}
That was my prototype method. How do I get the UUID?
$cache->set($object->uuid, $object);
Since you get can fetch the UUID from the object, it almost seems silly to call this with two arguments so I'm looking at this (well, with a proper exception):
sub set_object {
my ($self, $object) = @_;
die "Bad interface: no uuid() method"
unless $object->can('uuid');
return $self->set($object->uuid, $object);
}
Now here's the interesting bit: originally, I was going to have the caching system know how to cache our objects by checking inheritance. Hand it an object built on top of our object relational system and it would just know how to proceed. However, after a bit of thinking about it, I realized that was silly. Instead, I just want to be able to cache anything with a proper UUID method to disambiguate it. If I hadn't whipped up a quick prototype, there's a good chance I would have made the caching system dependent on our persistent objects and lost opportunities to cache other things.
Thus, by whipping up a quick prototype, I get a better chance to make more generalized objects and thus gain a more flexible, robust system. I've done this quite a bit and never really considered that the exploratory prototyping is what led to this.
This journal entry brought to you by the letters Y-A-G-N-I.