[messages] [Developers] Vassal code maintainability
mkiefte at dal.ca
Fri Jul 30 02:26:02 MST 2010
> 2. Unit tests anyone? I see a huge whack of unit tests under nio, but I
> assume those aren't authored by Vassal coders... Without unit test
> coverage, changing the Vassal engine code is like flying a trapeze
> without a net. How will you know if your change breaks any existing
JUnit would be a great idea.
> 3. Layering. Why are there awt imports on model classes like
> TriggerAction and GamePiece. Has anyone ever made an attempt to bring
> some Model-View-Controller discipline to the Vassal code base? I think
> this mixing of model and view is part of the reason we have strange
> things like keystrokes being the way you call a function in Vassal,
> which is the weirdest thing I've seen in a while!
That's something else we have to do.
> 4. Visitor pattern. A bunch of the confusion I've seen about how traits
> are resolved stems from mixing visting algorithms with the structures
> that those visiting algorithms operate on. I.e. I don't think traits
> should be responsible for doing things to other traits.
I understand what you're saying, but it doesn't bother me nearly as much.
It's a simple linked list. And traits like Obscurable have regulate
> Traits should
> just change state and send and receive events. Another layer on top of
> traits should then be responsible for the order traits are executed, and
> for managing the event bus. This would get rid of all this confusing
> "inner" and "outer" stuff.
That's really part of the design philosophy and not something that's easily
changed. I suspect traits were thought of like visible layers. Whatever is
underneath can be obscured by something above it. It's not really as weird
as you make out. My only issue has ever been the behaviour of
> There'd just be lists of things, and rules
> for how you iterate over those lists. Way easier to understand.
> Those are four things off the top of my head that I feel would help
> improve the maintainability of the code and reduce the chance of code
> changes introducing bugs in the future. Has anyone else considered
> introducing disciplines like these to the Vassal code base?
What you're talking about is an overhaul. It sounds great. But if you
don't want to see existing modules break, then it's going to take an order
of magnitude more work than you imagine.
I think JUnit tests would be the first order of business....
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the messages