[messages] [Developers] Vassal code maintainability

Tim McCarron timothy.mccarron at sbcglobal.net
Thu Jul 29 20:42:19 MST 2010


The road map should answer a lot of stuff for you. What the NIO stuff is for
- other code your looking at but isn't in use yet etc..

You can view that here
http://www.vassalengine.org/wiki/Roadmap

Joel and Mike can answer in more specifics

-----Original Message-----
From: messages-bounces at vassalengine.org
[mailto:messages-bounces at vassalengine.org] On Behalf Of fil512
Sent: Thursday, July 29, 2010 10:33 PM
To: messages at vassalengine.org
Subject: [messages] [Developers] Vassal code maintainability

Hey guys, I'm new to the Vassal coding world and have a bunch of typical
newbie questions.

1. What's with all the nio/zip source code?  It looks like it has
nothing to do with Vassal.  Shouldn't that be a jar dependency instead
of source code?

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
modules?

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!

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.  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.  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?

Ken

_______________________________________________
Read this topic online here:
http://www.vassalengine.org/forum/viewtopic.php?p=19015#p19015
_______________________________________________
messages mailing list
messages at vassalengine.org
http://www.vassalengine.org/mailman/listinfo/messages



More information about the messages mailing list