Regarding your chess example, I disagree. Having a "piece moveTo: aPosition" method is much less clean than having a "piece moves" message and a "board moveFrom

Regarding your chess example, I disagree. Having a "piece moveTo: aPosition" method is much less clean than having a "piece moves" message and a "board moveFrom: somePosition to: anotherPosition" message. Pawn captures would be handled similarly. #moveFrom:to: would check if the piece in somePosition can move to anotherPosition(or if it could capture to that position if the destination is occupied). If so, it moves the piece and handles any capturing. The logic of movement or of capturing isn't a quality of the chess pieces. The ways a piece can move or capture are qualities of those pieces. Having #moveFrom:to: as a message to the game-board allows you to keep all the code related to the way capturing and movement in chess works together, and keep the code for describing the movements of an individual type of piece with that type of piece. It also means that a piece doesn't need to know where it is on the board, or even what board it is on. You could even use a single object for all knights, another for all rooks, and so on without any negative consequences. However, if you do do that, there is a risk of introducing additional complexity in the Board class when it comes to dealing with castling, pawn double initial moves, en passant, etc. Double initial moves could be handled with a message on Pawn(#hasMoved) and using two Pawn objects, one with hasMoved set and one without it. The same could be done for King and Rooks for castling. En passant would probably require keeping an extra instance variable on Board to keep track of double initial moves.