Thread: SOLID Principles clarification and help with Classes and Methods

I'm very new to Java and i'm struggling a little with a project we've been set. I have to make a TicTacToe game, and it must contain 5 classes only : a driver class, GUI class, an abstract class for a computer player (randomly chooses between two strategies) which is extended to two classes of a Strategic computer class and a dumb computer class.

Everyone has different views on what should be on each class so I wanted a clarification.

My "driver" class includes the main method calling on the GUI class. And my GUI class consists of all GUI components, and the computer classes containing all the computer moves. I wanted to know where I would put all codes regarding to checking for a winning combination and invoking the computer moves?

Some say in the GUI class but some argue that this will be going against the SOLID principles. Then some say it should be in the driver class? But I am little unsure as to how I would make my driver class interact to check winning moves?

Would this game be on an applet? Whichever class has the main method to compare possible "known" combinations before you write it.

My "driver" class includes the main method calling on the GUI class. And my GUI class consists of all GUI components, and the computer classes containing all the computer moves.

That sounds like a good modular design to start with. Everybody has a clear and well-defined role so far. So your question then is, which class should be responsible for orchestrating everything together? Some class that will become the program's brain, keeping track of the entire state of the game and telling the other parts what to do and when (but not how, that's their business).

Those who say the GUI could have this logic are technically correct for very small applications like this, but those who say that would go against "solid" design principles are also correct and I believe even more so. It gets really subjective down in the details, but if I'm making a program that's going to get pretty big, I've always found it helpful to put most of the core logic somewhere other than in the GUI, and use the GUI programmatically as "a tool" rather than "The Brain."

So based on "solid" design principles, I would make the driver class the main brain. It should create and "own" the players, the 3x3 grid of cells, and the GUI, and should be in charge of orchestrating them all together and deciding what should happen and when amongst them. Kindof like a boss directing employees.