Object Oriented Programming (OOP) is a programming paradigm where problems are approached by dividing them in subunits called objects. It is differentiated from the procedural programming paradigm in that in procedural programming problems are divided in procedures which are usually functions. In the OOP paradigm, objects belong to classes and each instance of a class has attributes that characterize the object and the class defines methods that interact with objects. Classes can encompass objects that can have different attributes, therefore, defining how to tackle a problem involves determining the necessary objects and their classes. In order to do this, it is important to view the problem at a higher level and ignore the details of the parts. This ability is called abstraction and it is fundamental to design an OOP code.
Two of the fundamental principles for a successful Object Oriented approach are modularization and encapsulation. Modularization is the concept of dividing the code into very well defined parts. Each part should be able to be analysed and extended independently. At the same time, modularization implies that the interaction between parts is clearly defined. Creating modular code implies writing organized code where it is easier to find particular modules, read them, debug them and modify them according to what it is needed. On the other hand, encapsulation is defined as the integration of data and the methods that can be applied to that data. In Java, this is present in the form of classes. The idea behind the concept of encapsulation is that individual elements are responsible of their own state. This also allows to restrict the public access to some of the object’s components protecting the inner state of the class (information hiding). Additionally, modularization and encapsulation are principles that create a discrete structure that allow software developers to easily reuse code.
In OOP, inheritance is a mechanism used to reuse code and extend its functionality. With inheritance, a new class can be created from an already defined hierarchical class structure or from an individual class. This mechanism allows to provide all the functionality (attributes and methods) of the parent class (superclass) to the new class which is called subclass or child class. In Java, method overriding is also supported, where a method implementation is overridden by its implementation in the subclass. Furthermore, several classes can inherit from the parent class.
Applying the concept of abstraction to data means hiding the details of the implementation and only showing the main information to the client. Java allows to implement abstraction through abstract classes and interfaces. Abstract classes are classes that cannot be instantiated and can only be accessed through subclasses that inherit them. Abstract classes are used to generalize the behaviour of classes. Interfaces share with abstract classes the fact that they cannot be instantiated as well. They are used to standardise the behaviour of classes because in order to implement an interface, all the methods in the interface must be overridden. This tells the software developer what must be implemented.
The first step to structure the code is to abstract the problem in order to define the required classes that will be coded to ensure modularization and encapsulation. The entry point will still be Main.java and the proposed classes are: Game, Board, Player, HumanPlayer and Bot. The Game class will handle the game logic and will have a method to launch the game from the Main class. The Board class will handle everything related to the board: the display, the counter placement and the evaluation to consider if a player won or if there is a draw. The Player class will handle the functionality of all players. This means that the Player class will consider robot players and human players. The Player class will be the superclass of Bot and HumanPlayer classes. Bot will extend the Player class to incorporate the intelligence to create a computer move. On the other hand, HumanPlayer will extend the Player class to add the functionality associated with the evaluation of the input. This will create the required guarding to avoid wrong inputs in the game. Figure 1 shows the proposed structure as a class diagram in the Unified Modelling Language (UML).
Figure 1. UML of Connect 4 application.
The Player class was defined as the parent class of Bot and HumanPlayer. Consequently, Bot and HumanPlayer classes inherit from the Player class. In this scenario, the usage of an abstract class or an interface could be considered. I opted for the inheritance implementation because in this way the Player class can be instantiated and this allows to extend the number of players easily by creating an ArrayList that will store objects from the Player child classes. Additionally, this avoids code repetition in each subclass by implementing general methods in the superclass. Therefore, the system presented in Figure 1 indicates that using an interface or abstract class is not required. However, these elements could be implemented by dividing the classes into smaller subunits, but this would increase code complexity when it is not required, making it more difficult to read, extend and maintain the code.