Taking college courses in computer science never really prepare you for the world of writing reusable code. In the course of developing CBase Chess, I scrapped my internal board representation code 3 times. I rewrote my UI board twice. And yet, when it comes time to start developing a notation app, I realized that my code still isn’t quite flexible enough.
Once again I’m rewriting my code. I’m doing my best to follow the Model-View-Controller (MVC) design pattern, so there’s a separation between the actual model and the way it’s displayed. So for now I’m working on a UI board that doesn’t know any of the rules of chess (not even castling or en-passant) – it simply asks its delegate if moving from a square to another square is legal, and makes the move if it’s allowed by the delegate. My intention is to subclass this class so that moves like castling and en-passant will be made without any more information from the view’s delegate (currently the delegate would have to tell the view to clear the captured piece on an en passant capture, or to move the rook itself during castling). From there it wouldn’t be a far stretch to add logic into the subclass to enforce all the rules of chess, setting itself as its own delegate and keeping all the logic associate with the rules of chess within itself.
While this sounds like much more work, it will work out better in the long run. I already have a Position class which knows the rules of chess, so once the board view is finished it will be relatively easy to integrate the position class with the view. Furthermore, since I may release the board view as open-source, it would simply make more sense that one can add chess rules to a subclass, since another developer may come along and decide to use the class for suicide chess or some other variant.
I think the most important lesson I’ve learned through all this is that documentation is important. I put off documenting a lot of code because I thought it was good enough to use, that it was solid and would not need to be changed later, and that nobody else would use it. After just a very short time of not working on a piece of code, I have to go back and try to figure out exactly what I was doing when I was writing it. It’s not terribly hard, of course, since I wrote it, so I can understand it once I remember the mindset I was in when I wrote it. However, this time around I’m commenting everything so I’ll know exactly what to do if I ever want to change my code in the future (which, of course, won’t happen since it’s solid, won’t need to be changed later, and nobody else will ever use it 🙂 ).