Same Class Different Default Values

Cags

Contributor
Joined
Feb 19, 2004
Messages
695
Location
Melton Mowbray, England
I'm looking for guidance here on best practice. I recently programmed a Sudoku application which can help solve various forms of 'Doku' puzzles. These include normal Sudoku (9x9), GoDoku (9x9 with letters), SuperSudoku (12x12) plus a few more different types. Now each of these puzzles share exactly the same properties which include grid dimensions, mini grid dimensions, character set etc.

I created a 'Doku' class that contained each of these properties, but have been torn how to proceed after that. One option is to have an overload for the constuctor that excepts all the relavent data so for example...
C#:
Doku myDoku = new Doku(new Size(9,9), new Size(3,3), new Char { ... });
Another option I considered (and is the way I'm currently doing it) is to inherit from the doku class and simply have the constructor of the inherited class set all the default values for me. This in my opinion makes the code more readable as it allows me to simply use...
C#:
Doku myDoku = new Sudoku();
Basically all I'm asking for is if there is any reason this would be bad practice, it certainly works.
 
I would think first about how you're going to use this code. Do you have a menu where a user picks the puzzle type/size they want? Is it loaded from a file? Is this just a prototype with results output to the console?

I would think about the best way to create the class from how you'll use it and go from there.

From a pure technical standpoint, having inherited classes that provide the defaults is fine. You may also consider using static methods, such as Doku.CreateSudoku(), that provides the defaults.

-nerseus
 
The user can both pick from a menu, and load from a file. Static methods is a good idea, I must admit I never thought of that. Great now three methods to choose from, my biggest problem with programming is I tend to spend days refactoring and never getting any further along.

EDIT: For now I'll probably stick with the inheritance as it provides the ability for extensibility through the use of plugins.
 
I tend to lean more towards the special constructor side of things. I just like to see what is being created specifically. You might even consider simplifying the special constructor even further, for example, you always know you will have an nXn (square) board, so why pass in a size class? Pass in n and make the size class in the constructor.
 
I think that the static methods are ideal (depending on circumstances). For instance, you could have the Doku.CreateSuDoku method, the Doku.CreateGoDoku method, etc., plus a general purpose Doku.CreateCustomDoku method that accepts size and character type arguments. These methods would then correspond to the (hypothetical) "New SuDoku"/"New GoDoku"/"New Custom Doku" menu items. This method, I'd say, is the most flexible.

Note, however, that this method and an inheritance scheme aren't mutually exclusive. You could create a base class that accepts the appropriate values and derived classes that call base constructors specifying the proper values. The static Doku.CreateXXX methods could call appropriate default constructors for the derived classes. At the same time this approach would be dynamic enough to easily allow the program to be somewhat adaptable by allowing the user to enter a custom Doku.
 
Back
Top