Jake Scruggs

writes ruby/wears crazy shirts

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Tuesday 8-10-04

Well, I got the king's weirdo move logic straightened out. And the pawn's. But now I'm looking at my ChessBoard class and I'm unhappy. ChessBoard does a lot stuff and I'm beginning to suspect that all the chess pieces are going to have to know about it. Why, you ask? Lemme tell ya: In order to figure out if there is a checkmate I have to first figure out if the king is in danger. No problem: did it already. But checkmate means that the king not only is in danger but that there is no way to get it out of danger on the next move. One way to get out of check would be to move the king. So I need a findAllLegalMoves method in the king class. But to find all the legal moves, the king will have to know what pieces are on the board. Another way to get out of check is to take the piece that is threatening the king. I got that working earlier today. But the last way to get out of check is the killer. One of the king's men can shield the king by getting between it and the threat. So now I need to look at all the king's men and see if they can move into a blocking space. Of course, this means that all the piece objects need a findAllLegalMoves method and to do that they need to know about the board.

A UML diagram of my chess program would now have lots and lots of arrows heading towards the ChessBoard class. Which is terrible design. A small change in the ChessBoard would now mean that I have to change all of the chess pieces. How to break up this dependency nightmare? More interfaces acting as firewalls between my objects. Micah suggested I need to look at which methods each piece uses from the ChessBoard and create a different interface for each. So the king and pawn might each have their own interface with the ChessBoard, but the rest of the pieces would have a different and thinner interface (less methods). That's a pretty big bit of refactoring so I better have at it.

Yeah. The chessboard stuff again. I find it kind of sweet that distant-past-Jake would spend all this time trying to arrange the dependencies so as to make the classes loosely coupled. But it's also kinda ridiculous. Maybe a game like Go would have been a better candidate as its pieces don't need to know too much but Chess, with it's complicated rules and numerous corner cases, is very hard to tackle. Chess is like a business that's been running for a few hundred years -- any interesting problem is some sort of crazy exception to the general rules. So it was a good portent of things to come but a rather frustrating last project at Object Mentor.

0 comments :