I am facing problems about class inheritance design. It is shown in C++ as follows:
There are 2 kinds of classes, we call them Object and Component first.
Class Object uses class Component, but problem occurs with their subclasses.
For simple, there are 6 classes.
class BaseComponent{...};
class ComponentA: public BaseComponent{...};
class ComponentB: public BaseComponent{...};
class BaseObject {
public:
virtual bool doSomething()=0;
void setBaseComponent(BaseComponent*c){_c = c;}
BaseComponent* getBaseComponent() {return _c;}
private:
BaseComponent* _c;
}
class ObjectA : public BaseObject {
public:
bool doSomething(){ /*do someting related to ComponentA*/}
void setComponentA(ComponentA* a) {setBaseComponent(a);}
ComponentA* getComponentA()
{return static_cast<ComponentA*>(getBaseComponent());}
}
class ObjectB : public BaseObject {
public:
bool doSomething(){ /*do someting related to ComponentB*/}
void setComponentB(ComponentB* b) {setBaseComponent(b);}
ComponentB* getComponentB()
{return static_cast<ComponentB*>(getBaseComponent());}
}
Now the problem comes:
If I do like the above code, I have to check always the class relationship.
(for example, I have to check real class in ObjectB::getComponentB() when use static_cast)
If I change the code and use ComponentA directly in ObjectA, I'm abandoning the "Dependency inversion", which makes the code not convenient.
So, could anyone give me some advice?
So any subclass of BaseObject always needs the matching BaseComponent subclass?
Make the setter in BaseObject protected. It claims that you can give any object any component, and that's a promise the subclasses can't uphold if anyone but them has access to that setter.
Even better would be to make the component a constructor argument, if that's at all possible.
The idea of using interfaces instead of concrete classes is that when you use a pointer of the interface you do not have to worry about what is behind.
If you are returning the concrete ComponentA and ComponentB then you lose that.
Then, IMO, you should change these concrete classes to be able to return a pointer of BaseComponent and then you will not need the static_cast.
Related
In C++, does inheriting a common ancestor and inheriting an interface (and requiring definition of a method in derived classes) require multiple inheritance? Eg. do I have to do the following (instead of merging MyInterface and ParentClass):
class MyInterface;
class ParentClass;
class DerivedClass1;
class DerivedClass2;
class SomeOtherType;
class YetAnotherType;
class MyInterface {
public:
// Must be defined in all derived classes
virtual SomeOtherType my_common_fxn(...) = 0;
...
};
class ParentClass {
private:
// Common ancestor
YetAnotherType _useful_member;
}
class DerivedClass1 : MyInterface, ParentClass {
public:
// Do some things with _useful_member, using approach #1
SomeOtherType my_common_fxn(...);
...
}
class DerivedClass2 : MyInterface, ParentClass {
public:
// Do some things with _useful_member, using approach #2
SomeOtherType my_common_fxn(...);
...
}
void fxn_or_method_using(ParentClass);
Is it possible to (elegantly) merge the functionality of MyInterface and ParentClass into a single class? (I believe that as MyInterface is an ABC I cannot use this type as a parameter to fxn_or_method_using.)
Apologies in advance if this is a duplicate- I've searched but none of the existing C++ questions appeared to line up. Q's and/or A's may have been over my (untrained) head.
There's nothing wrong with your inheritance model.
But in C++ you need a pointer or reference for polymorphism. Your fxn_or_method_using takes its parameter by value. That has several problems. It causes slicing, it prevents polymorphic function calls, and it can't work for an abstract type because you can't create instances of those.
If you change fxn_or_method_using to take its parameter by reference not value, then you can declare it as referring to MyInterface if you wish. All the disadvantages disappear and you get the polymorphic behaviour you want.
No. You can mix virtual and pure virtual and concrete inheritance all from the same class in C++ with no problems.
class baseClass{
public:
blah1(){
//stuff
}
virtual blah2();
virtual blah3() = 0;
};
class derivedClass : baseClass
{
};
After writing a test, I determined that the this pointer in an interface is not equal to the this pointer of the concrete class, meaning I can't just use a C-style cast on it.
class AbstractBase {...};
class AnInterface {
public:
AnInterface() {...} // need AbstractBase * here
~virtual AnInterface() {...} // and here
};
class Concrete : public AbstractBase, public AnInterface {};
My interface needs a base class pointer to the concrete class inheriting it in the constructor and destructor in order to handle interface related registration and deregistration.
Every concrete object that inherits the interface needs to inherit the abstract base class first, it is always first in the layout.
For the constructor it is not all that hard, I can add a pointer in the interface constructor and pass this from the concrete class. But the destructor doesn't have any parameters, so I am in the dark there.
The solutions I came up with so far come with overhead:
1 - store the pointer in the interface to be used in the destructor - adds in one pointer worth of memory overhead
class AnInterface {
public:
AnInterface(AbstractBase * ap) {...}
~virtual AnInterface() {...} // and here
private:
AbstractBase * aPtr;
};
...
Concrete() : AnInterface(this) {}
2 - create an abstract method in the interface and implement it to return this in the concrete class - adds in the overhead of indirection for the virtual call
class AnInterface {
virtual AbstractBase * getPtr() = 0;
};
class Concrete : public AbstractBase, public AnInterface {
AbstractBase * getPtr() { return this; }
};
3 - dynamic_cast is even worse
Is there a more efficient way to achieve this?
IMO if decoupling between the base class and the interface is really needed, both solution 1 and 2 have tolerable overheads, certainly nothing that will be a problem on contemporary hardware.
But since you say that the interface is designed to work with the functionality, provided in the base class, then maybe the decoupling is not a good thing.
I mean if the problem is with inheriting multiple interfaces which all inherit the base class, or the "dreaded diamond" problem with inheritance, you can simply use virtual inheritance.
All of your concerns seem like micro-optimizations. Assuming you truly can't separate out your interface from your implementation (in which case, why are you using interfaces in the first place?) I would just use dynamic_cast and be done with it, even though it's pretty heavyweight. If I were stuck on a platform where RTTI isn't an option then I'd use option 2.
Your design has some flaws.
You should consider using CRTP as from the Mixin aspect, which saves you from keeping an extra pointer of the concrete derived.
template<typename Derived>
class AnInterface {
public:
AnInterface() {
Derived* derived = static_cast<Derived*>(this);
AbstractBase* abstractBase = static_cast<AbstractBase*>(derived);
} // have AbstractBase * here
~virtual AnInterface() {...} // and here
};
class Concrete
: public virtual AbstractBase
, public AnInterface<Concrete> {
AbstractBase * getPtr() { return this; }
};
I have a base class with a bunch of functionality and a derived class that extends that class but there are a few methods in the base class that don't make sense on the derived class.
Is it possible to do something to prevent these method(s) from being used by the derived class?
Class A
{
...
public:
void SharedMethod();
virtual void OnlyMakesSenseOnA();
}
Class B : public Class A
{
...
public:
void OnlyMakesSenseOnB();
}
The following obviously doesn't work but is it possible to do something similar so that the compiler doesn't allow a certain base class method to be called?
Class B : public Class A
{
...
public:
void OnlyMakesSenseOnA() = 0;
}
No, and this is completely wrong. If the member function is not callable in the derived type you are breaking the Liskov Substitution Principle. Consider whether this is the correct inheritance relationship. Maybe you want to extract SharedMethod to a real base and provide two separate unrelated A and B types.
This isn't as easy of an answer as I had hoped, but a coworker suggested that this situation is an indication of bad design and that I should re-think my inheritance structure by adding a new base class that only contains common functionality:
Class Base
{
...
public:
void SharedMethod();
}
Class A : public Base
{
...
public:
void OnlyMakesSenseOnA();
}
Class B : public Base
{
...
public:
void OnlyMakesSenseOnB();
}
Edit: Thanks to #David for providing a name for the rule that I'm trying to break. B is not a "Behavioural Subtype" of A because it fails the "counterfeit test". Therefore, deriving B from A violates the Liskov Subtitution Principle.
According to this slide deck, the counterfeit test is as follows:
Suppose I promise to deliver you an object of class T, but
instead I give you an object x of class S.
You can subject x to any series of method calls you like
(chosen from T’s signature).
If x behaves in a way that is not expected of a T object,
then you know it is a counterfeit, x has failed the test.
If all S objects always pass every counterfeit test, then S is
a behavioural subtype of T.
You could also just throw an exception if the invalid method is called on the derived class. It doesn't catch the bug at compile time but at least it prevents it from accidentally being used a runtime.
Class B : public Base
{
...
public:
void OnlyMakesSenseOnA() { throw Exception(); }
}
Yes, it's possible and quite simple, if we're talking about an external call. You can hide parent's method with private methods of derived class. Works with the static methods as well.
Tested on cpp 98, 11, 14. Try yourself in C++ shell.
class Base{
public:
void methodBase(){};
static void methodBaseStatic(){};
};
class Derived : public Base{
//private: //(private on default)
void methodBase(){};
static void methodBaseStatic(){};
};
Normal operation:
int main()
{
Base b;
b.methodBase();
Base::methodBaseStatic();
Derived d;
return 0;
}
Compilation error
int main()
{
Derived d;
d.methodBase();
Derived::methodBaseStatic();
return 0;
}
This question explains nicely how to create interfaces in C++. Here is the code:
class IDemo
{
public:
virtual ~IDemo() {}
virtual void OverrideMe() = 0;
};
class Parent
{
public:
virtual ~Parent();
};
class Child : public Parent, public IDemo
{
public:
virtual void OverrideMe()
{
//do stuff
}
};
One thing is not clear to me though: What do I need the class Parent for?
You're not required to inherit from anything besides your interface to make use of the interface, however you can do so and that answer shows you how. The point is you're not required to only inherit from one or several interfaces, you can also add classes as bases of your class - almost any combination of classes and interfaces is permitted.
Actually, I have no idea, why. You can do the following as well:
class IDemo
{
public:
virtual ~IDemo() {}
virtual void OverrideMe() = 0;
};
class Child : public IDemo
{
public:
virtual void OverrideMe()
{
//do stuff
}
~Child()
{
}
};
Everything depends only on your program's architecture and what actually Parent and Child are. Look at the C# example - IDisposable is an interface, which allows one to dispose resources used by the class, which implements it. There is no point in requiring a base class - it would even make using IDisposable harder to use, because maybe I don't want the base class functionalities (despite fact, that every .NET class derives from Object, but that's another story).
If you provide more information about your actual program's architecture, we may be able to judge, whether a base class is needed or not.
There's another thing worth pointing out. Remember, that in C++ IDemo actually is a class, it's an interface only from your point of view. So in my example, Child actually has a base class.
I am trying to refactor some code while leaving existing functionality in tact. I'm having trouble casting a pointer to an object into a base interface and then getting the derived class out later. The program uses a factory object to create instances of these objects in certain cases.
Here are some examples of the classes I'm working with.
// This is the one I'm working with now that is causing all the trouble.
// Some, but not all methods in NewAbstract and OldAbstract overlap, so I
// used virtual inheritance.
class MyObject : virtual public NewAbstract, virtual public OldAbstract { ... }
// This is what it looked like before
class MyObject : public OldAbstract { ... }
// This is an example of most other classes that use the base interface
class NormalObject : public ISerializable
// The two abstract classes. They inherit from the same object.
class NewAbstract : public ISerializable { ... }
class OldAbstract : public ISerializable { ... }
// A factory object used to create instances of ISerializable objects.
template<class T> class Factory
{
public:
...
virtual ISerializable* createObject() const
{
return static_cast<ISerializable*>(new T()); // current factory code
}
...
}
This question has good information on what the different types of casting do, but it's not helping me figure out this situation. Using static_cast and regular casting give me error C2594: 'static_cast': ambiguous conversions from 'MyObject *' to 'ISerializable *'. Using dynamic_cast causes createObject() to return NULL. The NormalObject style classes and the old version of MyObject work with the existing static_cast in the factory.
Is there a way to make this cast work? It seems like it should be possible.
You have to virtually inherit from ISerializable (I just tested it with VS2010). This is a common issue called the Diamond Problem, where the compiler does not know wich hierarchy path to take.
EDIT:
This should do it:
class NewAbstract : public virtual ISerializable { ... }
class OldAbstract : public virtual ISerializable { ... }
You can get round it by casting to one of your immediate bases first eg.
virtual ISerializable* createObject() const
{
NewAbstract*const na = dynamic_cast< NewAbstract* >( new T() );
return dynamic_cast< ISerializable* >( na );
}
Don't inherit virtually from both NewAbstract and OldAbstract. Pick one to inherit virtually from. I think that may take care of it.
Look up "dreaded diamond" and virtual inheritance. They may help you.