In my spare time, I am building a Sudoku solver to try to get the hang of OOP in PHP. A Sudoku puzzle, for those of you who don't know, is in its most common form a 9x9 matrix of numbers from 1 to 9, with 3x3 squares delineated in a tic-tac-toe like pattern. Some numbers are filled in in advance. The goal of the puzzle is to fill in the remaining numbers, so that no row, column or 3x3 square contains the same number more than once.
To do this, I made a number of classes. A Cell can be an element of a Constraint , which are the rows, columns, and 3x3 squares. A Sudoku is a collection of Constraint s and Cell s. I have a SudokuSolver class which dynamically includes source files with SolverHelper subclass class declarations, and instantiates one of each subclass. A helper has a Solve() function that takes a Sudoku as an argument. It examines the Constraint s and asks its cells to eliminate value possibilities based on what it finds. The program itself just loops over the helpers until none of them report that they were able to eliminate any possibilities anymore.
But the fact that all cells in a row or column line up, has certain corollaries that are taken advantage of in certain solution techniques. So I need to differentiate between rows/columns, and other Constraint s. I could have the rows and columns in different arrays, which is not a bad solution. This has the advantage of allowing a good optimization opportunity: no column ever intersects another, for instance. I could also add a boolean property IsLinear .
Or, and now we get to my question: I could subclass the Constraint class to have a LinearConstraint . But that class would be empty. It would not need to override anything in the Constraint class. It would be a pair of curly braces, and that's it; a LinearConstraint object is special by virtue of being an instance of its class. If I wanted or needed to have special code that pertains to linear constraints, I could always add it. My question is: is the fact that I'm considering declaring and using an empty class, a sign that I'm doing something wrong? Am I being too abstract and theoretical about this?
Source: Tips4all, CCNA FINAL EXAM
An empty class is not at all bad. People use that in various other scenarios; especially in Exception specialisation.
ReplyDeleteI do not believe that it will be any worse than adding a flag into the Constraint class, to differentiate the two types. I would much rather prefer the extended class, for at least the sake of code readability.
I may be misunderstanding the question, so bear with me if I am! From my understanding you wish to have different types of Constriant classes so that the Solve() function will act differently depending on the type of grid? (For optimization reasons, presumably).
ReplyDeleteExtending the Constraint class in this way would certainly be one way of distinguishing the types, and I don't think is particularly bad practice.
You may however wish to in future have even more different types of Constraint (I dunno, say you went nuts and decided to do 3D sudoku or something). In this case it may be better to turn the original Constraint class into an abstract class and extend that. You could set up how ever many subconstraints you wished, and they would all have the same functionality (plus any added functions unique to that constraint).
This way you could set up your empty LinearConstraint subclass and not have to worry about shuffling everything around again when you decide to have even more Constraint subclasses.