I need to develop a C++ solution to represent an object with features, where the objects and features are represented by different objects, but the actual implementation of the association is implemented in a derived class which exists to encapsulate an external implementation. I know that this kind of thing is typical of inheritance-related problems, so I want opinions on the correct solution. The implementation part should be seen as a sort of API boundary -- the user code should not see it, or see it only once in order to select the implementation.
Here's an example:
#include <cstdio>
// External implementation 1
class SomeShape {};
class SomeBody { public: SomeShape *shape; };
// External implementation 2
class OtherShape {};
class OtherBody { public: OtherShape *shape; };
//////////////
class Shape
{
public:
virtual const char *name() { return "Shape"; }
};
class Body
{
public:
virtual void setShape(Shape *s) = 0;
};
class Factory
{
public:
virtual Shape *makeShape() = 0;
virtual Body *makeBody() = 0;
};
//////////////
class AShape : public Shape
{
public:
SomeShape *someShape;
virtual const char *name() { return "AShape"; }
};
class ABody : public Body
{
protected:
SomeBody *someBody;
AShape *shape;
public:
ABody() { someBody = new SomeBody; }
virtual void setShape(Shape *s)
{
shape = static_cast<AShape*>(s);
printf("Setting shape: %s\n", s->name());
someBody->shape = shape->someShape;
}
};
class AFactory : public Factory
{
public:
virtual Shape *makeShape()
{ return new AShape(); }
virtual Body *makeBody()
{ return new ABody(); }
};
//////////////
class BShape : public Shape
{
public:
OtherShape *otherShape;
virtual const char *name() { return "BShape"; }
};
class BBody : public Body
{
protected:
OtherBody *otherBody;
BShape *shape;
public:
BBody() { otherBody = new OtherBody; }
virtual void setShape(Shape *s)
{
shape = static_cast<BShape*>(s);
printf("Setting shape: %s\n", s->name());
otherBody->shape = shape->otherShape;
}
};
class BFactory : public Factory
{
public:
virtual Shape *makeShape()
{ return new BShape(); }
virtual Body *makeBody()
{ return new BBody(); }
};
Thus, the role of the above is to allow the user to instantiate Body and Shape objects, which exist to manage associating underlying implementations SomeShape/SomeBody or OtherShape/OtherBody.
Then, a main function exercising both implementations could be,
int main()
{
// Of course in a real program we would return
// a particular Factory from some selection function,
// this should ideally be the only place the user is
// exposed to the implementation selection.
AFactory f1;
BFactory f2;
// Associate a shape and body in implementation 1
Shape *s1 = f1.makeShape();
Body *b1 = f1.makeBody();
b1->setShape(s1);
// Associate a shape and body in implementation 2
Shape *s2 = f2.makeShape();
Body *b2 = f2.makeBody();
b2->setShape(s2);
// This should not be possible, compiler error ideally
b2->setShape(s1);
return 0;
}
So, the parts that I am not happy about here are the static_cast<> calls in setShape(), because they build in an assumption that the correct object type has been passed in, without any compile-time type checking. Meanwhile, setShape() can accept any Shape, when in reality only a derived class should be accepted here.
However, I don't see how compile-time type checking could be possible if I want the user code to operate on the Body/Shape level and not the ABody/AShape or BBody/BShape level. However, switching the code so that ABody::setShape() accepts only an AShape* would make the whole factory pattern useless, for one thing, and would force the user code to be aware of which implementation is in use.
In addition it seems like the A/B classes are an extra level of abstraction over Some/Other, which exist only to support them at compile time, yet these are not intended to be exposed to the API, so what's the point... they serve only as a kind of impedance-matching layer, forcing both SomeShape and OtherShape into the Shape mold.
But what are my alternative choices? Some run-time type checking could be used, such as dynamic_cast<> or an enum, but I'm looking for something a little more elegant, if possible.
How would you do this in another language?
Analysis of your design issue
Your solution implements the abstract factory design pattern, with:
AFactory and BFactory are concrete factories of the abstract Factory
ABody and AShape on one hand and BBody and BShape on the other hand are concrete products of abstract products Body and Shape.
The Axxx classes form a familiy of related classes. So do the Bxxx classes.
The issue you worry about is that an the method Body::setShape() depends on an abstract shape argument, whereas the concrete implementation expects in reality a concrete shape.
As you've rightly pointed out, the downcast to the concrete Shape suggests a potential design flaw. And it will not be possible to catch the errors at compile-time, because the whole pattern is designed to be dynamic and flexible at run time, and the virtual function can't be templatized.
Alternative 1: make your current design a little bit safer
Use the dynamic_cast<> to check at runtime if the downcast is valid. Consequence:
the ugly casting is very well isolated in a single function.
the runtime check is only done when necessary, i.e. the only time you set the shape.
Alternative 2: adopt a design with strong isolation
A better design, would be to isolate the different products. So one product class would only use the abstract interface of the other classes of the same family and ignore their concrete specificity.
Consequences:
very robust design enforcing superior separation of concerns
you could factorize the Shape* member at the level of the abstract class, and perhaps even de-virtualize setShape().
but this comes at expense fo rigidity: you couldn't make use of family specific interface. This could be very embarassing, if for example the goal is that the family represents a native UI, knowing that products are highly interdependent and need to use native API (that's the typical example in the book of the Gang of 4).
Alternative 3: templatize dependent types
Opt for a template based implementation of your abstract factory. The general idea, is that you define the internal dependencies between products, using a template implementation.
So in your example Shape, AShape and BShape are unchanged as there is no dependency to other produts. But Body depends on a Shape, ad you want to have ABody depending on AShape, whereas BBody should depend on BShape.
The trick is then to use a template instead of an abstract class:
template<class Shape>
class Body
{
Shape *shape;
public:
void setShape(Shape *s) {
shape=s;
printf("Setting shape: %s\n", s->name());
}
};
Then you would define ABody by deriving it from Body<AShape>:
class ABody : public Body<AShape>
{
protected:
SomeBody *someBody;
public:
ABody() { someBody = new SomeBody; }
};
This is all very nice, but how shall this work with the abstract factory ? Well same principle: templatize instead of virtualize.
template <class Shape, class Body>
class Factory
{
public:
Shape *makeShape()
{ return new Shape(); }
Body *makeBody()
{ return new Body(); }
};
// and now the concrete factories
using BFactory = Factory<BShape, BBody>;
using AFactory = Factory<AShape, ABody>;
The consequence is that you have to know at compile time which concrete factory and concrete products you intend to use. THis can be done using C++11 auto :
AFactory f1; // as before
auto *s1 = f1.makeShape(); // type is deduced from the concrete factory
auto *b1 = f1.makeBody();
b1->setShape(s1);
With this approach you will no longuer be able to mixup products of different families. The following statement will cause an error:
b2->setShape(s1); // error: no way to convert an AShape* to a BShape*
And here an online demo
Related
In below code I have abstract class TestAlgModule which I will be exposing to library users and there are several functionalities they can use such as VOLUME, MIXER and so on. However, suppose users need a new function which is added only in MixerManager then I need to add that in TestAlgModule abstract class and now suddenly all the derived class needs to add that without any benefit.
How do I avoid this?
#include <iostream>
using namespace std;
enum {VOLUME, MIXER, UNKNONWN};
class TestAlgModule {
public:
virtual void open(int type) = 0;
virtual void close(int type) = 0;
};
class volumeManager : public TestAlgModule
{
public:
void open(int type) {}
void close(int type) {}
};
class mixerManager : public TestAlgModule
{
public:
void open(int type) {}
void close(int type) {}
void differentFunction() {};
};
/* users calls this to get algModule and then call functions to get the job done */
TestAlgModule *getTestAlgModule(int type) {
switch(type) {
case VOLUME:
return new volumeManager();
case MIXER:
return new mixerManager();
default:
break;
}
return nullptr;
}
int main() {
TestAlgModule * test = getTestAlgModule(MIXER);
test->open();
//test->differentFunction(); this can't be called as it is not part of abstract class and users are exposed only abstract class
return 0;
}
If something is not clear please let me know and I will do my best to answer it. I am looking for a better way to do this i.e. change in VolumeManager should be independent of MixerManager.
If you want to use an abstract factory, like you did in above code, then you need to return a pointer to the base class. That is correct. And then you need to invoke all functions through the base pointer.
By the way, please do not use raw pointers. Please use std::unique pointers instead.
There are 2 possible solutions.
Add the interface functions as a none pure, but still virtual function to your base class, with a default behaviour.
virtual void differentFunction() {}
Because of the other pure functions, the base class is still abstract. This may lead to a fat interface. But in many cases it is an acceptable solution.
The second possibility is to downcast the base class pointer to your needed pointer, using dynamic_cast and checking the return value of the dynamic cast.
if(mixerManager* mm = dynamic_cast<mixerManager*>(test)) {
mm->differentFunction();
}
All this depends of course on the overall design and what you want to achieve. But the above 2 are the standard patterns.
There are also other design patterns that may fit your needs, like builder or prototype. Please check.
In C++, I have several classes inheriting from an abstract super class. Subclasses have a static attribute sharing the same name type but of course have different values. My question is what is the best approach to implement this and what are the pros and cons for each implementation.
PS:
There are some related discussions like here but most don't explain why approach (which works on my machine) 1 below should not be used. Besides, the subclass methods in approach 2 are not static and wwe will have to get an instance to invoke them.
Apporach 1: uinitialized const static in superclass
class Abstract {
public:
const static int type;
};
class C1: public Abstract {
public:
const static int type = 1;
};
class C2 : public Abstract {
public:
const static int type = 2;
};
Approach 2: using virtual functions instead of variables
class Abstract {
public:
virtual int get_type() = 0;
};
class C1: public Abstract {
public:
int get_type() {return 1;}
};
class C2 : public Abstract {
public:
int get_type() {return 2;}
};
Other approaches that I'm not aware of...
EDIT:
As some answers/comments mentioned below, I'm trying to identify actual type at runtime. However I cannot really think of a nicer design.
To make it concrete, let's say Abstract=EduInst for educational institution, C1=Univ, C2=College, etc. I have a std::map<Key, EduInst*> storing all institutions, which are generated at runtime depending on user input. At times I need to operate only on Univs or Colleges. What is a good way to implement this?
First the warnings:
Inheritance describes an "is kind of" relationship with the base class. It only makes sense when you are storing different kinds of objects in the same container, when those kinds of object absolutely share the same interface, and when no special handling is required on any one of the derived classes (i.e. when you, the object's consumer don't need to know its type).
Furthermore, if you only have a few kinds of the same thing, and those kinds of thing can possibly be known at compile time, then it's probably a mistake to use inheritance.
If your inherited object must identify its actual type to a client, this is further evidence that inheritance is the wrong solution - since now you're going to use code to find code, which is a bad idea (it's not testable, and it's liable to go wrong when your program is in a state that you didn't anticipate).
Furthermore, if you have objects that are dissimilar but need to be stored in the same container, then boost::variant is probably the solution you're looking for. You would then use boost::static_visitor to perform operations on the object in the variant. The advantage of this is that is absolutely type-safe and the compiler won't allow you to forget to handle a type.
Having said all that...
approach 1 won't work because if you have the type of the derived class already, you'll always get the base class' type.
approach 2 will work but it's horrid and an indication of a broken design.
You can't have "virtual" static members.
Approach one is for finding out the "type" attribute of a class, the second for finding out the "type" attribute of an instance.
To put it differently: to use the first, you need to know the class; to use the second, you need to know the instance.
It's impossible to write code where you know neither.
Note that approach one can give you unexpected results if you use type inside a function in a base class.
For instance,
class Abstract
{
public:
int get_type() const { return type; }
};
// ...
C1 c;
std::cout << c.get_type();
will output 0, since that is the value of Abstract::type.
A variation of the second approach lets you avoid the virtual function if you sacrifice the space of another member:
class Abstract {
public:
// ...
int get_type() const { return type; }
protected:
Abstract(int t) : type(t) {}
private:
int type;
};
class C1: public Abstract {
public:
C1() : Abstract(1) {}
};
class C2 : public Abstract {
public:
C2() : Abstract(2) {}
};
I have a class hierarchy that I designed for a project of mine, but I am not sure how to go about implement part of it.
Here is the class hierarchy:
class Shape { };
class Colored { // Only pure virtual functions
};
class Square : public Shape { };
class Circle : public Shape { };
class ColoredSquare : public Square, public Colored { };
class ColoredCircle : public Circle, public Colored { };
In part of my project, I have a std::vector of different type shapes. In order to run an algorithm though, I need to put them in a std::vector of colored objects (all of which are derived types of different concrete shapes, so I need a method to cast a Square into a ColoredSquare and a Circle into a ColoredCircle at runtime.
The tricky thing is that the 'shape' classes are in a different library than the 'colored' classes.
What is the best method to acomplish this? I have thought about doing a dynamic_cast check, but if there is a better way, I would rather go with that.
Edit 1:
Here's a bit better of an Example:
class Traceable {
public:
// All virtual functions
virtual bool intersect(const Ray& r) = 0;
// ...
};
class TraceableSphere : public Sphere, public Traceable {
};
class IO {
public:
// Reads shapes from a file, constructs new concrete shapes, and returns them to
// whatever class needs them.
std::vector<Shape*> shape_reader(std::string file_name);
};
class RayTracer {
public:
void init(const std::vector<Shape*>& shapes);
void run();
private:
std::vector<Traceable*> traceable_shapes;
};
void RayTracer::init(const std::vector<Shape*>& shapes) {
// ??? traceable_shapes <- shapes
}
void RayTracer::run() {
// Do algorithm
}
You could use the decorator pattern:
class ColorDecorator public Colored
{
ColorDecorator(Shape* shape): m_shape(shape) {}
... //forward/implement whatever you want
};
If you want to store a Square in a Colored vector, wrap it in such a decorator.
Whether this makes sense is questionable though, it depends on your design and the alternatives. Just in case, also check out the visitor pattern (aka double dispatch) which you could use to just visit a subset of objects in a container or treat them differently depending on their type.
Looks like you are going to design the class library in a "is-a" style, welcome to the Inheritance-Hell.
Can you elaborate a bit about your "algorithm" ?
Typically it is bad design if you need to "type-test" on objects, since that is what you want to avoid with polymorphism. So the object should provide the proper implementation the algorithm uses (design-pattern: "strategy"), advanced concepts utilize "policy-based class design".
With careful design, you can avoid casting. In particular, care for SRP. Implement methods carefully so that they use a single Interface to achieve a single goal/fulfill a single responsibility. You have not posted anything about the algorithms or how the objects will be used. Below is a hypothetical sample design:
class A {
public:
void doSomeThing();
};
class B{
public:
void doSomeOtherThing();
};
class C:public A,public B{};
void f1( A* a){
//some operation
a->doSomeThing();
//more operation
}
void f2(B* b){
//some operation
b->doSomeOtherThing();
//more operation
}
int main(int argc, char* argv[])
{
C c;
f1(&c);
f2(&c);
return 0;
}
Note using the object c in different context. The idea is to use only the interface of C that is relevant for a specific purpose. This example can have classes instead of the functions f or f2. For example, you have some Algorithms classes that do some operation using the objects in the inheritance hierarchy, you should create the classes such that they perform a single responsibility, which most of the time requires a single interface to use, and then you can create/pass objects as instance of that interface only.
Object-oriented programming only makes sense if all implementations of an interface implement the same operations in a different way. Object-orientation is all about operations. You have not shown us any operations, so we cannot tell you if object-orientation even makes sense for your problem at all. You do not have to use object-oriented programming if it doesn't make sense, especially in C++, which offers a few other ways to manage code.
As for dynamic_cast -- in well-designed object-oriented code, it should be rare. If you really need to know the concrete type in some situation (and there are such situations in real-life software engineering, especially when you maintain legacy code), then it's the best tool for the job, and much cleaner than trying to reimplement the wheel by putting something like virtual Concrete* ToConcrete() in the base class.
I think the simplest & cleanest solution for you would be something like the following similar to what Chris suggests at the end.
class Shape {
virtual Colored *getColored() {
return NULL;
}
};
class Colored { // Only pure virtual functions
};
class Square : public Shape { };
class Circle : public Shape { };
class ColoredSquare : public Square, public Colored {
virtual Colored *getColored() {
return this;
}
};
class ColoredCircle : public Circle, public Colored {
virtual Colored *getColored() {
return this;
}
};
I do not completely understand this statement though
" The tricky thing is that the 'shape' classes are in a different library than the 'colored' classes."
How does this not allow you to do what's being suggested here (but still allow you to create a class ColoredSquare) ?
I have to create family of objects based on customer type.
I have one base abstract class ApplicationRulesFactory, which defines
virtual interface. A lot of concrete customer classes inherits from this class.
The problem is that for some customers say CustomerB we do not use the objects Rule2 and Rule3 because the features in the application which are using these objects Rule2 and Rule3 are disabled from the application user interface for that customer, so we are not really needing to instantiate these objects at all.
The simplified code is here, i.e in reality ApplicationRulesFactory has much more virtual methods, and more concrete customer classes that inherits from it :
class ApplicationRulesFactory
{
virtual Rule1* GetRule1() = 0;
virtual Rule2* GetRule2() = 0;
virtual Rule3* GetRule3() = 0;
.....
};
class ACustomerRulesFactory : public ApplicationRulesFactory
{
Rule1* GetRule1()
{
return new ACustomerRule1();
}
Rule2 * GetRule2()
{
return new ACustomerRule2();
}
Rule3* GetRule3()
{
return new ACustomerRule3();
}
};
class BCustomerRulesFactory : public ApplicationRulesFactory
{
Rule1* GetRule1()
{
return new BCustomerRule1();
}
Rule2* GetRule2() // not needed
{
// what to return here ?
}
Rule3* GetRule3() // not needed
{
// what to return here ?
}
};
So how should I go to implement this :
1) Return some default implementation in the base class ApplicationRulesFactory :
class ApplicationRulesFactory
{
virtual Rule1* GetRule1() = 0;
virtual Rule2* GetRule2() { return new Rule2DefaultImpl();}
virtual Rule3* GetRule3() { return new Rule3DefaultIml();}
};
But this seems wrong, to inherit new classes(Rule1DefaultImpl,Rule2DefaultImpl) from Rule1, Rule2, and probably make them with empty implementation just for the purpose of returnig them like default implementation in the ApplicationRulesFactory
2) or in the concrete class return the default implementaion and leave these methods pure virtual in the base class
class BCustomerRulesFactory : public ApplicationRulesFactory
{
Rule1* GetRule1()
{
return new BCustomerRule1();
}
Rule2* GetRule2()
{
return new Rule2DefaultImpl();
}
Rule3* GetRule3()
{
return new Rule3DefaultImpl();
}
};
These solution also seems very ugly to redefine the methods in every concrete customer class although they are not needed.
3) Also I have a feeling that maybe I should not use inheritance like this, cause this violates the IS-A rule for inheritance, cause a significant number of the methods are not applicable to all of the concrete customer classes, but don' t how to go to implement this without inheritance.
Any ideas
If ApplicationRulesFactory doesn't make sense for certain kinds of Customers, then it isn't the right abstraction for you.
Your domain knows what makes sense, so why would it be asking for Rule2 and Rule3?
Make the object which knows that it only needs Rule1 use a factory which gives it Rule1 only. Give it a context so that it can get the factory it needs.
You seem to be mixing the interface and the factory into one. Surely the interface should be a class on its own, with various rules that have a default behaviour in the base-class and then an overridden behaviour in the derived class, and then the factory returns a pointer to the requested class that implements the right rules for that case.
But maybe I've misunderstood what you are trying to achieve...
If the rules can never be used, I would suggest just returning a null pointer from a base class implementation (mostly like your option one except not even bothering with a default implementation since it can never be called).
I am upgrading an old application which was written for a specific hardware interface. I now need to add support for a modern hardware to the existing application.
To do this, I would like to create a class for each hardware type, and assign a variable to one type or the other whenever the user selects which hardware is in their system.
For example:
Class HardwareType1 and Class HardwareType2 both exist having the same member functions.
object HW;
if (userHwType = 1)
// initialize HW as a HardwareType1 class
}
else{
// initialize HW as a HardwareType2 class
}
Now I can use HW.doSomething() throughout my code without a conditional for hardware type every time I interact with the hardware.
I'm sure this is pretty basic but to be honest I don't even know what this is called or what terms to search on for this one.
Thanks!
Create an an abstract base class, and derive two concrete classes from it: one implementing type1 and the other implementing type2:
class Hardware
{
public:
virtual ~Hardware() {};
virtual void doSomething() = 0;
};
class Hardware1: public Hardware
{
public:
void doSomething() { // hardware type1 stuff. }
};
class Hardware2: public Hardware
{
public:
void doSomething() { // hardware type2 stuff. }
};
Then create the necessary instance:
std::unique_ptr<Hardware> hardware(1 == userHwType ? new Hardware1() :
new Hardware2());
hardware->doSomething();
If you compiler does not support C++11 then std::unique_ptr will not be available to you. An alternative smart pointer would boost::scoped_ptr (or boost::shared_ptr).
Use polymorphism with a common abstract base class, like this:
class HardwareBase
{
public:
virtual void Open() = 0;
virtual void Close() = 0;
virtual ~HardwareBase() {};
};
Then derive your concrete hardware types:
class HardwareType1 : public HardwareBase
{
public:
virtual void Open() {...}
virtual void Close() {...}
};
And select the required hardware instance:
std::unique_ptr<HardwareBase> hw;
if (userHwType == 1)
hw.reset(new HardwareType1());
else
hw.reset(new HardwareType2());
// And use it like this:
hw->Open();
Note that you now need a pointer to the selected object instance.
Use a unique_ptr to automatically delete it on exit.
The term to search for is polymorphism; that's the general term for interacting with different types through a common interface.
In C++, if you need to select behaviour at runtime, the usual approach is to define an abstract interface, which acts as a base class for your concrete types, using virtual functions - the function to call is chosen at runtime depending on the true type of the object.
// Abstract interface
class Hardware {
public:
virtual ~Hardware() {} // needed to safely delete objects
virtual void doSomething() = 0; // must be implemented by each concrete type
};
// One concrete type
class HardwareType1 : public Hardware
{
HardwareType1() { /* initialise */ }
void doSomething() { /* implementation for this type of hardware */ }
};
// Another concrete type
class HardwareType2 : public Hardware
{
HardwareType2() { /* initialise */ }
void doSomething() { /* implementation for this type of hardware */ }
};
Now you can choose which to create, and then interact using the abstract interface:
// Create the correct type, depending on user input
std::unique_ptr<Hardware> hw
((userHwType == 1) ? new HardwareType1 : new HardwareType2);
// Do the right thing depending on the type
hw->doSomething();
You could search for factory method. That is the name of the pattern you are trying to implement