I have an object that uses many helper objects to send messages back and forth. For some reason, I struggled with the exact implementation of those helper objects and just couldn't get them quite right. My tests would pass, but I would get stuck on the code and didn't get an API fleshed out.
This morning, I realized that I had it backwards. I'm now writing the main object and the API of the helper objects is incredibly obvious. I don't have to stop and think about how they work, I just know. Work is going much faster now. I'm going to have to remember this in the future.
Re:Architecture?
Ovid on 2003-04-28T20:50:58
It's pretty simple, really. Let's say that I have an object that sends messages to other objects. We'll call those "helper objects". What API should I use with the helper objects? If I start by trying to design them, it may not be immediately clear how they are used.
For example, I have a variant of a status system that I've been using, but I needed to improve on the old API. My purchase orders can be "pending", "sent", "cancelled", or "received". These statuses are actually helper objects that allow the purchase order to inspect itself and override some internal behavior. (There's a reason why these weren't subclasses, but that would be a pointless digression). So how do I create "status" objects? I knew roughly how to implement them, but I couldn't nail it down exactly. However, once I started to flesh out the purchase order object, creating the status system was obvious:
sub create {
my ($class, $data) = @_;
# new pos are *always* pending
my $pending = POStatus->retrieve(POStatus->PENDING);
$data->{status} = $pending;
$class->SUPER::create($data);
}When I was trying to create the API by starting with the status system, it simply wasn't obvious how the type system was going to be used. Once I had to use the type system, I didn't even think about it. The API was obvious.
Re:Architecture?
jonasbn on 2003-04-29T09:12:25
Thanks for the explanation - It made more sense the second time:)
