I am making a specific single board game in Java. I would like to have an interface "Position" with methods contracted to describe the number of "men" on different squares on board, score etc. But if I call it "Position" I can not find a good name for the implementing classes ! I have read that I should not do "IPosition". Suggestions ?
Michael Boehm wrote: But if I call it "Position" I can not find a good name for the implementing classes ! I have read that I should not do "IPosition". Suggestions ?
hmm.. why ? suppose you named an interface as IPosition , then implementation class as Position ok. in future if you want one more implementation class then what you will name for that ?
see the java api , take an example of List . it is an interface , ArrayList,LinkedList, ... these are all implementation classes . but again that is you wish to name the interface as IPosition/Position . naming an interface with prefix *I* habit comes from c++
My personal preference is to avoid naming interfaces starting with 'I'. I'm kind of curious why you're creating an interface for position. Do you expect to have a need for more than one kind of implementation?
I want to be able to change implementation with minimal changes to classes and code using "Position"s. Say you were working with chess and wanted a Position interface, what would you call a first implementing class ?
ChessPosition would probably be my first choice. I guess the difficulty I'm having is that position seems to be a very concrete concept, like a point or an integer, and I'm not seeing how you would implement it differently.
Lets say you also want to develop som AI for playing your chosen game. Now you realise that your first chosen way to implement positions is not very efficient for doing eg. MinMax searching in your searchtree of positions being evaluated using some game-specific heuristic taking intu account the placement of the "men" ondifferent parts of the board. Now it would be nice to have all your developed algos for the search not getting into trouble because you change representation from something human-readable to a number of bitmaps ) Someone said: Always code to interfaces !
Right, but the position (i.e., x,y coordinates, hex coordinates, etc.) really wouldn't need an interface. The movement would, and that's what I would write an interface for. You could then account for the different algorithms there. As for 'always' programming against interfaces, you probably should modify that to 'prefer' .
I recently read some place that Sun suggests that you use adjectives for interfaces. For example, Positionable. I first found it a little weird but have come to like it because it frees you to name your classes and you want (Position) and you can easily recognize your interfaces.
Revisting this I see I was not so clear. By Position i meant the whole position in the boardgame and not a "geometric" position eg. on a chessboard. So for instance with chess, a Position would hold info about what pieces where on which squares. I read some coding conventions for a larger project, think it was an open source project, and they suggested that a first class implementing the interface Interface should be named DefaultInterface. It works, but am not sure it is pretty
Michael Boehm wrote:By Position i meant the whole position in the boardgame and not a "geometric" position eg. on a chessboard. So for instance with chess, a Position would hold info about what pieces where on which squares.
I still don't see why you need an interface for this. However if you can imagine two different classes which would implement this requirement in two different ways, that might help you name the interface. But personally I can't imagine that, so I can't think of a name.
Or were you perhaps thinking of generalizing your Position entity to describe positions in games other than chess? Like Go, or bridge?