[computer-go] Choice of interface naming style

[Mark Boon]

On 12-aug-2006, at 5:12, Stefan Nobis wrote:
>
> But what about "Basic", "Default", "Main", if you really can't come up
> with something more sensible?
>

Yes, I still do use "Default", "Abstract" and occasionally "Basic" :-)

Thinking a bit more about it I think I'm going to stick to using the  
common names for the interfaces (or for a class if I foresee only one  
likely implementation) and using deviations for the implementations,  
possibly even using Impl at times if I can't find anything  
appropriate. Using the 'I' prefix for interfaces becomes rather  
pointless if all type declarations have an 'I' prefixed.

The main reason for this decision is that most objects are created  
through factory classes anyway so that the pooling of the objects is  
hidden in the factory. I'm going to use this method throughout. In  
that case the interface names are the only ones used often in the  
code. The names of the implementing classes are only used in one  
place and that is in the factory class.

So replacing one implementation by another is going to be totally  
painless. All you need to do is provide the new implementation and  
change the one line in the factory class where it's allocated and  
you're done. This will greatly facilitate experimenting with  
different implementations of different building blocks.

I had already begun making wrapper classes around arrays that contain  
board information and such. But for performance reasons I often still  
accessed the raw arrays directly internally. A quick experiment that  
replaced all array access by using a method call to the abstract  
interface showed I lose another 10%-15% percent if I replace all of  
the raw array access. So "if (board[xy]==EMPTY)" becomes "if  
(board.get(xy)==EMPTY)" and "board[xy] = BLACK;" becomes "board.set 
(xy,BLACK);". Compilers must have become pretty sophisticated over  
the years and replace the method call by the raw array access to the  
array underneath. Otherwise I'd have expected a much greater  
performance hit. Making methods 'final' has no performance benefits,  
the compiler figures out itself when a virtual call can be avoided. I  
must say I don't know exactly how it does this, maybe it looks at the  
inheritance tree when classes are loaded and compiled.

So I'm actually considering doing that everywhere. It will cause a  
significant performance hit at first, but it will allow maximum  
flexibility to be used by other projects. And I can always make a few  
implementations of performance-critical modules using raw array  
access later and win back most, if not all, of the initial  
performance loss.

Mark