I suppose this is as good as it’s going to get. It can solve all hard Sudokus from web sudoku, but none of the evil ones that I tried.
It’s quite OO, as there is one [font=monospace]Set[/font] class, that [font=monospace]Box[/font] and [font=monospace]Line[/font] extend from. [font=monospace]Sudoku[/font] extends from [font=monospace]Box[/font].
The [font=monospace]Set[/font] holds most methods, such as [font=monospace]getRow( int )[/font] and [font=monospace]getColumn( int )[/font].
Each object inheriting from [font=monospace]Set[/font] knows how to solve itself as much as possible. Also, each [font=monospace]Set[/font] has a one-dimensional array of [font=monospace]Cell[/font] objects. Each [font=monospace]Cell[/font] object knows its possibilities, and, once figured out, its value. They hold their possibilities in [font=monospace]Cell::value[/font]. The [font=monospace]Cell::id[/font] property is only used for cell identification and testing.
It’s important to note that you could instantiate a [font=monospace]Line[/font] object outside of the context of a Sudoku, and have it solve itself. Same goes for [font=monospace]Box[/font]es. When you instantiate any class which inherits from [font=monospace]Set[/font], the constructor will want a one-dimensional array of integers, with [font=monospace]-1[/font] or [font=monospace]null[/font] representing an unknown cell.
At any time, you can print any [font=monospace]Set[/font] class, because they all have [font=monospace]__toString()[/font] methods which print them as tables. [font=monospace]Sudoku[/font] overrides [font=monospace]Set[/font]'s method, to allow several [font=monospace]Box[/font] objects to designate the borders, as would occur in a normal Sudoku puzzle.
Following are the files, in no particular order.
