[computer-go] Choice of interface naming style

[Mark Boon]

Yes, I usually have the same knee-jerk response. If an interface has  
only one implementation then you don't need the interface. At least  
in principle. But by defining the interface separately I set up the  
possibility for someone else to provide another implementation  
without having to change anything else. If I use a class instead then  
at least the interface should remain the same if it gets split into  
multiple implementations, otherwise it would result in an awful lot  
of code-change. So I suppose that's an argument in favour of using  
the 'Impl' convention.

Since working on a project where the biggest, most complex class was  
called SimpleTextField, I can't bring myself to prefixing any class  
with 'Simple' anymore. I've seen too often that classes called  
'Simple' don't stay that way. Of course refactoring tools make name- 
changes a lot less painful than it was at the time.

Mark



On 11-aug-2006, at 18:39, Weston Markham wrote:

> One of my own knee-jerk attitudes is that if your interface class and
> implementation class are competing for the same name, then they
> probably should be the same class.  The existence of one particular
> implementation that is special in some way that makes it "the"
> FooImpl, then perhaps the interface is not really abstracting anything
> away from the implementation.
>
> Or perhaps you simply need to ask yourself, "in what way does this
> particular implementation of Foo differ from others?"  I often find
> myself naming classes "SimpleFoo", etc., if the only distinction is
> that I happened to write it first, and have not yet found a need for
> any other implementation.
>
> Weston
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/