Hello copeg, thanks so much for answering this. I've been watching this topic like a mother hen over her chicks.
Originally Posted by
copeg
I'm not sure (...) whether this is a design or implementation question
At this point it is design. If you have a solution in another language or in UML, that would be great to start with. On this particular problem I stand nowhere.
Break the problem down into its individual requirements.
You mean split up the editor from the simulator? The way I see it the validation system stands over both. It will color the pawns when a new postion is selected, and the combo box or menu of suggestions will be filled by this same validation system. Of course I'll have to start with the coloring, but I would like to build this system so that it can later on be used
as is to implement the suggestions generator (simulator).
I'll give you my thoughts on the design of the move validations: write an interface which provides the ruling. You can then plug this into each piece dependent upon what you wish to validate and how you wish to evaluate it.
It sounds like you're on to something. Could you elaborate a bit around it, please? I know interfaces like mouse handler interfaces, but more than that it's a bit fuzzy. You wouldn't have a url towards an example by any chance?
After rereading this, I'd like to clarify something. The 'move' does not need to be validated. Only the new position. It doesn't matter where the pawn comes from that is important. Only the position it occupies. Like I said, it's not a game, like chess or checkers, where you can make illigal moves. It's more a bit like a magnet structure, where opposing poles will not stick together.
You can then plug this into each piece dependent upon what you wish to validate and how you wish to evaluate it.
There is only one type of pieces. However, depending where they are located, different rules apply. To use the magnet analogy: if you place a magnet next to another, it will react differently than when you place it by itself.
This will decouple the actual 'piece' object from the behavior. You can then implement the interface/behavior however you wish.
A friend of mine, whom I haven't seen in a while, once talked about test case rules. I didn't understand it at the time, but he told me to write
rule classes for every normal class in the model. Would that make sense?
for something like a chessboard different lookup tables for each behavior might do the trick
Lookup tables would be very interesting actually. There are so many rules, described in lots of different books, that I'd need a convenient way to implement them one after the other and test them thoroughly.
Is there a (Java) source code available online for a chess game implemented this way?
Sorry for the many questions. If anyone can answer only one of these, please do. I'm very passionate about this particular subject. Thank you in advance.
Alice