OOP… Code => Organized
You can’t get into software development without being introduced to object oriented programming. There is a great reason for this. OOP makes your code more manageable and testable. In this post I will walk through an example to outline some of the benefits of OOP.
Delegation of responsibilities
Before you write a single line of code, you’d better understand the problem you are trying to solve. Work to identify the different functional groups and behavior of the problem you are trying to solve. Each group will likely become its own class. Behavior of each group will determine how you setup inheritance.
Let’s look at an example, coding a tic tac toe CLI game. What is the structure of our game example? We have the board itself, the players, the pieces, a way to display the data, and the game itself. These would all get their own classes.
What is the behavior of the different classes? The board itself will contain the board data and to do that it’ll need to have functionality to update the board’s data set. The player could be either human or could be AI. We’ll go on and break both player types into their own classes. The pieces really only need to provide a reproducible object for either an X piece or an O piece. The display class will provide the visual display for all the messages and board data. The game class should hold all the specifics to the game itself. Such as whose turn is it, is the game over, and the like. Seems simple enough.
Identify any shared behaviors
The human and AI players will both be asked to make a move, have a name, and or piece(X/O) preference. Any functionality or state that is shared between the human and AI classes can go into a parent class called player. Both the human and AI classes can inherit that shared behavior from a parent class. We’ll call it player class. This will help keep your code DRY. Whatever unique behavior the child classes have can be written into the child class itself.

The more specific you can make your classes and methods the easier it’ll be to test. The goal is single responsibility for each class. This goes a long way towards maintainability and programmer happiness!
