Basically, does this look sensible?
sure. I would probably have done things differently (I like generic listener designs), but it looks sensible. Write the code, and if it still looks sensible then, feel happy :D
Deciding where to make classes, components and blocks at the moment is my biggest mental hurdle.
and if you're not into compiler design (or something like that), it's likely to remain for the foreseeable feature (IMHO). Making these kind of decisions is what we often call "decomposition". There's always many ways to do it. I'm in a coffee break, so I'll write up how I tend to do it....
I usually draw a few things on paper, and the arrows I draw show where my contracts (work interfaces) need to be. Next I write the work interfaces.
Then I create unit tests for the to-be-created implementations using some mock objects framework for all dependencies. These test the work interface contract as I drew it.
Then I create trivial implementations (ie no I/O, no threads, no external dependencies....no blahblah at all) that simulate what they should be doing later on. I add implementation ideas on making things work better in comments.
Run the tests. Probably add more tests as my idea of the contract solidifies. Modify the interfaces one or two times. Add in custom exceptions.
Coffee break.
Then I start modifying the implementations to actually do what they should be doing, rerunning the tests often.
When things seem in order, I start writing up things like metadata, config files, etc, and start doing integration tests (if you're using Merlin, you use the AbstractMerlinTestCase, if you're using Fortress or Pico, you just create and populate a container instance). This is often a frustrating part as I manage to forget config file formats quite often, but backed by all my running unit tests I can usually figure out the issues.
Coffee break.
When all that works, I'll usually do another sketch (this time what things actually look like), then refactor things bit by bit as I change things in the sketch. Until I'm sort-of happy with the layout.
This is usually when I make my first commit (so peers can review and so I can go back and look at what on earth I meant in the first place). I'll have a coffee break and talk to one of to those peers for feedback. If no peer is available, I read slashdot instead.
The next point should usually be to refactor the test cases into an abstract test case that just tests the work interface contract, and a subclass that runs the tests in the abstract case, plus a few of its own (like for constructors), on the implementation. This is especially important if you will have multiple implementations of the same interface, since basic testing of other implementations just involves a minimal extension of the abstract test case.
I'm often too lazy to do all of those things though. In practice I'll often get enthousiastic on an idea, then just write an implementation immediately, add minimal tests that show it works, take a coffee break, then start componentizing. But always regret it later because that's actually more work.
An interesting observation about the size of the subsystem I tackle at once: it is limited to the size of the paper I'm drawing on. I used to be much more productive in one of my old jobs: we had lots of A3 paper lying around. But I think I produced more bugs too :D
I'd round of with a joke involving paper and coffee, but can't think of any.
-- cheers,
- Leo Simons
PS: as always, if anyone enjoyed or valued reading, please add the parts worth saving to the wiki @ http://wiki.apache.org/avalon/.
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
