Multiple Inheritance and Casting

[Eggman002]

Not at all. You implement the method on the class, and it redirects, you NEVER perform a cast.

What about when implementing the method on the class doesn't make sense (or is impossible). For example what if you are inheriting from a class where you don't have the source (i.e. from a code library or something). Or what about something like:

class Person
{
  ...
}

class Banker : Person
{

}

class BasketballPlayer : Person
{
    int GetPointsPerGame();
}

Now suppose you have a "Person" object and you know it is a BasketballPlayer object (for various reasons). You need to call the GetPointsPerGame.

Obviously you shouldn't just put "GetPointPerGame" into the Person class since that doesn't make sense. The only way to get the info you need is to cast it to a BasketballPlayer.

I realize this example is a bit arbitrary, but it illustrates my question fairly well. It seems like you are suggesting that casting should always be avoided, yet there are cases where it seems to me it is necessary.

[TheCPUWizard]

Now suppose you have a "Person" object and you know it is a BasketballPlayer object (for various reasons). You need to call the GetPointsPerGame.

The question is directly related to "HOW" you know the Person is a basketball player, and "WHY" you would be iterating through a collection of "People" where you only want to do something for Basketball players.

Consider if you wanted to know the average points per game globally....Would you take the "world census" (billions of people), look at each persons "job description" and then gather the data?

I rather tend to doubt it. Rather you would go to some specific collection (NBA Team roster?) and use that as your source.

In other words, the very model you used as your illustration seems to be very poorly designed - and maybe the actual program is also.

btw: Regarding the "dont have source", this often means using aggregation/composition along with the adapter patterns instead of derivation...

[Eggman002]

So I am revisiting this issue and I wonder what people think about the following solution. Is it appropriate? Is it good design?

To avoid multiple inheritance, I use the following setup:

class Mode
{
}

class ModeType1 : Mode
{
}

class ModeType2: Mode
{
}

class SpecialModeType1: ModeType1
{  
}

class SpecialModeType2: ModeType2
{
}

Then to assist with code reuse and to avoid having to wrap everything in an if statement or a switch statement I do the following:

class SpecialModeCommon
{
  static void ACommonFunction(Mode currentMode)
  {
    if(Verify we are in SpecialMode1)
    {
      SpecialModeType1* mode = static_cast<SpecialModeType1*>(currentMode);
      ...
      Access any values required and assign them to variables
      ...
    }
    else if(Verify we are in SpecialMode2)
    {
      SpecialModeType2* mode = static_cast<SpecialModeType2*>(currentMode); 
      ...
      Access any values required and assign them to variables
      ...
    }

    ...
    Do any processing on the common values.
    ...
  }
}

This means I don't have to worry about multiple inheritance issues. I can still reuse most of the code (except for the accessors which will have to be written for each mode).

[TheCPUWizard]

I can not recommend in favor of ANY design which involves run time checking of types.

I also want to repeat that code re-use is NEVER a reason for utilizing inheritance.

[Eggman002]

I can not recommend in favor of ANY design which involves run time checking of types.

There is no runtime checking of types happening here. That was not clear in the sample. There is runtime checking of a flag which indicates which mode we are currently in.

Though the flag is not much better than checking the type (Better performance but not necessarily better design), this framework is heavily used in the code base that I am working on and I can not change that. So in this case I would rather stick to the existing framework for consistency rather than have multiple ways of doing things.

I suppose a better way to handle this would be to have a ModeManager to handle all Modes and then a SpecialModeManager to handle SpecialModes. The SpecialModes would be included in both ModeManagers but if I wanted only the SpecialModes I can go to the SpecialModeManager. Or something like that. But again in the framework I am working with this would be a huge departure from how everything else is implemented. And if I were to do this I would still be checking the above mentioned flag to figure out whether to go to ModeManager or SpecialModeManager so the only thing I am saving is having to to a static_cast.

I would still be interested in hearing and discussing the "correct" solution though for future reference.

I also want to repeat that code re-use is NEVER a reason for utilizing inheritance.

Inheritance was not used for code re-use in the above example. SpecialModeCommon does not inherit from anything and nothing inherits from SpecialModeCommon. A static function was created for code re-use.

[TheCPUWizard]

Why not just use"double dispatch" and be done with it?????

[Eggman002]

Why not just use"double dispatch" and be done with it?????

Sorry, I am not overly familiar with the concept of Double Dispatch. I Googled it but I am not really sure how it would apply here.

[TheCPUWizard]

class Foo
{
   void Execute(Bar1 &b) {cout << "Processing a Bar1"; }
   void Execute(Bar2 &b) {cout << "Processing a Bar2"; }
   void Execute(Bar &b) { b.Dispatch(this) }
}

class Bar
{
   virtual void Dispatch(Foo &f) { f.Execute(this); }
}

class Bar1: Bar
{
  virtual void Dispatch(Foo &f) { f.Execute(this); }

}

class Bar2: Bar
{
  virtual void Dispatch(Foo &f) { f.Execute(this); }
}

int main()
{
Bar *b = new Bar2();
Foo f;
f(*b);
}

Foo will process the CORRECT Bar2 routine.

[laserlight]

On a related note, you might want to search for "visitor pattern".

[JohnW@Wessex]

I also want to repeat that code re-use is NEVER a reason for utilizing inheritance.

I've come across a template technique that appears to use inheritance for code reuse. What are your opinions on this?
Or do you consider that Communicator doesn't break the IS-A rule in this case?

class Printer
{
public:
    virtual void Print() = 0;
};

class Console_Printer : public Printer
{
public:
    void Print();
}

class Stream_Printer : public Printer
{
public:
    void Print();
}
 
class Comms
{
public:
    virtual void Send() = 0;
};

class Serial_Comms : public Comms
{
public:
    void Send();
};

class Net_Comms : public Comms
{
public:
    void Send();
};

template <typename TComms, typename TPrinter>
class Communicator : public TComms, public TPrinter
{
};

int main()
{
    Communicator<Net_Comms, Console_Printer> communicator;
    Communicator<Serial_Comms, Stream_Printer> communicator2;

    communicator.Send();

    communicator2.Print();
}

[potatoCode]

Sorry, I am not overly familiar with the concept of Double Dispatch. I Googled it but I am not really sure how it would apply here.

Hello Eggman002
Just in case you want it
http://en.wikipedia.org/wiki/Design_...puter_science)
and this might help too...just in case
http://en.wikipedia.org/wiki/Open/closed_principle

[TheCPUWizard]

I've come across a template technique that appears to use inheritance for code reuse. What are your opinions on this?
Or do you consider that Communicator doesn't break the IS-A rule in this case?

In my view, it does NOT break the IS-A rule, in fact it conveys the "IS-both-A" for each of the template arguments. Of course it does open up the various issues which occur when multiple inheritance of concrete classes is introduced into an application...

One thing (which may be in the real implementations that got purged from the sample) that I would "expect" is that communicator provided some "communication" betweeen the two template parameter classes.

[JohnW@Wessex]

One thing (which may be in the real implementations that got purged from the sample)

No, I just made it up on the fly. I haven't actually used this technique. I think it was described as implementing 'policies', in that a concrete class could be made up from different building blocks, each block implementing a 'policy'. I'm not sure that they were expected to always 'know' about each other, but just provide a set of independent implementations.

Sort of compile time 'Dependency Inversion Principle'?

[JohnW@Wessex]

Here it is

http://en.wikipedia.org/wiki/Policy-based_design

[TheCPUWizard]

No, I just made it up on the fly. I haven't actually used this technique. I think it was described as implementing 'policies', in that a concrete class could be made up from different building blocks, each block implementing a 'policy'. I'm not sure that they were expected to always 'know' about each other, but just provide a set of independent implementations.

Sort of compile time 'Dependency Inversion Principle'?

Taken directly from the first paragraph of the link tht John provided:

The central idiom in policy-based design is a class template (called the host class), taking several type parameters as input, which are instantiated with types selected by the user (called policy classes), each implementing a particular implicit interface (called a policy), and encapsulating some orthogonal (or mostly orthogonal) aspect of the behavior of the instantiated host class.