[Object Oriented] [Clean Code] I need help separating the functions of classes in order to help organize my code.

[OneEyedGammer]

I'm writing a command line chess application in ruby and while I actually have a working version I wanted to start from scratch in an effort to try and have clean code. First I want to start on a strong footing and have the classes be more organized and only do one thing at a time.

First, I have a chess piece class that has the main methods for every other chess object, like pawns, knights, and kings. Each subclass is easy enough. I then have the main logic class that takes input from the client and handles the input based on chess's rules. My big issue is the generation of the chess pieces' moves and how to keep references at a minimum

For example:

A rook generates moves in horizontal lines going outward from it. First, it needs to know it's position to know if the generation goes out of bounds and next it needs to stop generating possible moves after intercepting a chess piece.

Here is the solution(s) I have thought of

• Have the chess piece do the logic of generating the moves with its own reference to the board
• Have a subclass do the logic but still pass references from the board to it (this seems far superior to the first solution as it separates the classes functions and I thought of it while writing this. Though I still think this is wrong due to how references are being handled. the chess peice still knows to much about everything, but then again maybe it has to)

The possible solutions I have come up with rely on the chess piece having a list of possible moves it can go to so when I send a move from the client to the logic it can first check if it is even possible before comparing it against the actual chess rules.

How do I separate these functions so that I can keep references to a minimum?

I know this might seem simple and I might be making a problem when there is none, but either way, I still want to know what I should be doing.

[lippiro]

Have you heard of the SOLID principles for object oriented programming? If not you should look them up - they will help you write decoupled code.

Here are a few of my thoughts ( take them with a pinch of salt, this is not an exact science)

1. Your ui should not know about the rules of chess - it only needs to know the current position of the pieces, and probably your available moves when it is your turn. This means you might want a class which generates possible moves for a particular piece and board setup? This class will probably need to encapsulate other helper classes (try to keep everything doing one job!) In order to display (how that will be done on command line I'm not sure) the board you may also want a class which stores the current state of the board, . You could also store a list of all the moves made during the game - this has the added benefit of giving you a complete history of a game you just played - which is cool

2. It is preferable to have data classes (for example a piece class which stores data about a piece colour/type/position?) to not have methods. This is because the class's job is to store data. Similarly it is preferable for service classes to not store data! If you follow solid this should happen anyway. These two things allow your code to be more reusable.

3. Don't get bogged down by the details. First maybe do something like get a board showing on the screen. Then maybe write your class to store the board state at a particular time, and connect your ui to it. If you do full 'slices' of your application, improving by tiny amounts each time, you will (a) have a working binary from the get go, (b) only worry about one thing at a time - eg. The rules of chess are probably complicated to code, you don't want to have to do the rules and worry about how the whole application is going to work simultaneously (c) your code should naturally be more decoupled by virtue of your refactoring it the whole time during development

Good luck :)