views:

79

answers:

4

I'm currently refactoring some code to make it more testable. Specifically, I am extracting the interface of several classes to allow easy creation of test doubles.

I'd like to keep the public interface the same to this code, naming the interface after the original class.

However this leaves me with the problem of what to call the original class.

I'm using C++.

If my interface is:

class ServiceClient;

What should I call the contrete, I've come up with a few options that I'm not convinced by:

class ConcreteServiceClient;
class ServiceClientImpl;
class StandardServiceClient;
class BasicServiceClient;

What conventions do people use?

+1  A: 

I would change the name of the interface class.

class ServiceClientInterface {};

Then place the concrete implementations in seprate namespaces:

namespace MyService
{
    class Client: public  ServiceClientInterface {};
}

namespace MyServiceTest
{
    class TestClient: public ServiceClientInterface {};
}

Or something completely different.
PS. I am into full names. I don;t like the the short 'I' is interface thing. Your taste may vary.

Martin York
I have decided to use postfix Interface as this solves the problem and has the added bonus of showing which classes are actually interfaces as C++ has no way of enforcing this.
Dave Hillier
A: 

ServiceClientInterface / ServiceClient, or ServiceClient / ServiceClientImpl. The others sound too artificial.

DevSolar
+1  A: 

ServiceClientImpl makes the most sense to me. It's the one that most clearly tells you what you need to know. That this is the implementation behind a ServiceClient.

"Standard" and "Basic" tell you nothing useful really. Is there a nonstandard ServiceClient too? What exactly is standard about this one? Does it live up to some ISO standard or what? And Basic sounds like there's an "Advanced" version as well.

"Concrete" might work, I've just never liked that terminology.

jalf
A: 

Normally, I reserve "Impl" for the pimpl idiom. I use a full "Interface" on abstract base classes. For concrete implementations, drop the Interface and prefix with what specialization this is:

class ServiceClientInterface {
   // some pure virtual methods
};


class XMLServiceClient {
   // Or whatever "service" it is
};

class TestServiceClient {
   // some well defined
};
Todd Gardner