设计界面

Question

I have what I believe is a fairly common problem. There is an interface called IService , and some derived classes that implements this interface; ServiceA, ServiceB, ServiceC and ServiceD.

ServiceA and ServiceB needs a function called getSomeType() to be exposed, but this function is not needed in the other derived classes. Also ServiceD needs another function exposed that the other derived classes doesn't need. How should I solve this problem? I feel that using dynamic_cast is not the right way to do it, or is it? I also considered creating a new interface so that ServiceA and ServiceB implements two interfaces.

class IService
{
public:
   virtual IService() {};

   virtual void start() = 0;

   virtual void stop() = 0;
};

class ServiceA : public IService
{
public:
    void start() override;

    void stop() override;

    ISomeType * getSomeType();
};

Answer 1

Derive IServiceAB from IService, derive ServiceA and ServiceB from IServiceAB, and derive ServiceD from IService.

One other way is too have a look into the decorator pattern (design patterns).

Answer 2

There most important tool in your design arsenal is a so-called 'substitution principle'. When you use public inheritance with polymorphism (btw, in C++ world we usually do not say 'implements interface', since interface is not a C++ term) you are claiming so-called IS-A principle - that is, you claim that for the outside observer ServiceA is, for all intents and purposes, IService. No more, no less. Everything which exists in IService exists in ServiceA. Everything (visible outside) which exists in ServiceA, exists in IService.

Whenever you feel the need to do a dynamic_cast , you are clearly violating this principle - because it means that IService is no longer ServiceA, you need to specifically cast to it.

Solution. Do not use public inheritance with polymorphism for classess which do not follow IS-A principle. In your case, ServiceA is not IService, which means, IService is not a suitable base class for ServiceA.

Answer 3

This is often a tricky problem. If, instead of service, we say we deal with animals - because we can use that as a proxy for "things that can do some things, but not other things". Say we have the animals Fish , Bird , Cow , Dog and Cat .

So, we think of things animals in general can do:

• Move - in different ways, eg Swim , Fly , Walk
• Make a noise - call this Talk
• Have properties such as length, number of legs, weight, etc.
• Some animals can be trained to "do stuff" (dog can fetch, a parrot can "talk" on demand),
• A cow can produce milk, but (for practical purposes), none of the others.

So, we have for example Fish , which, obviously, can swim , but can't talk , which a Dog or Bird can do. A Bird can fly but can't Swim [yes, there are excellent swimming birds, I'm simplifying reality]. A Dog can make sounds, but certainly can't fly. A Cat can make sounds, swim (reluctantly), but won't be able to Fetch .

So, it becomes a problem of how we represent this ability to do certain things, but not other things.

There are several solutions, but ultimately, there are two possible solutions

• Dummy functions that don't do anything (eg empty function) for those functions that aren't applicable: Talk on Fish , or Swim on Bird .
• Conditional code - such as a CanSwim function, that answers whether the animal can swim or not. In which case the Swim function may throw an exception if it's still being called.

Ultimately, somewhere, we need to know that they are different types of animals, and that some can do some things, others can't. Either asking a bird to swim will fail (and shouldn't happen) or will "do nothing". You really have to determine what the right thing to do is.

I do have this problem in my compiler project. I have an "abstract syntax tree" that represents the source code in a parsed form. So it has nodes for variable declarations, function declaratins, assignments, binary operations, while-loops, for-loops, etc, etc. These have the same basic interface, which provides a CodeGen function that actually makes the (intermediate representation) - so a binary expression of a + b will generate code to load a , load b and then add the two together. Codegen for a function will call codegen for the body of the function, etc.

There are half a dozen other general purpose functions that apply to (almost) all AST entries. But there are a few operations that only really make sense on a particular situation, for example when dealing with binary operators, strings are not supported by the intermediate representation as add for concatenation. So can't just load, load and add - have to call the strcat function. For these special cases, I use dynamic_cast to check if the, in this case, the type is matching the string type, and if so, fall into the "special string operation" code-path. I could add a isString function for ALL of the types, but it would be rather awkward and not much benefit, as MOST of the time, it's not important. I don't think this is a great solution.