Anders Abel
2010-03-03 07:39:43
views:
207answers:
4I don't think it's a pimpl idiom. If it is, the implementation pointer should be pointing to another class right. But in my code above, it is pointing to the class itself.
jasonline
2010-03-03 08:01:49
Hmm.. you're right... then it more looks like a "decorator" pattern implementation, but still that does not explain the m_Iface member.
Anders Abel
2010-03-03 08:03:06
I've added some info on how the m_Iface is called. Meanwhile, I'll check the decorator pattern.
jasonline
2010-03-03 08:09:28
Any idea how the factory and the normal class should be related? Is it another design pattern perhaps?
jasonline
2010-03-03 09:11:00
The factory looks like flawed implementation of the "Abstract Factory" pattern. I think it is flawed because CreateClassA is implemented as a stub doing nothing instead of a pure virtual method. As Matthieu points out below, I think that the one writing the code had an ambition to implement several patterns, but didn't completely succeed.
Anders Abel
2010-03-03 09:56:43
A:
This looks much more C than C++. In any object-oriented language, you would use inheritance and virtual functions to get this behaviour.
Using an internal pointer to an implementation class is perfectly fine (the pimpl idiom), but this pointer would not normally be accessible to callers. And I don't get the interface pointer at all.
Gorpik
2010-03-03 07:55:01
@Gorpik, I've added more classes. I think it's for some event handling and used together with some factory. Yes, I don't get the use of the interface pointer. I couldn't find yet where it is used.
jasonline
2010-03-03 07:58:17
+2
A:
I am afraid the names used do not have the usual meaning, so without examples of what is put in or how they are used, it's going to be difficult to guess.
There are 2 design patterns that you should check, that make heavy use of this kind of self-recursion (at class level*):
And I am afraid that you are looking at something that fails to emulate either of those.
In the Decorator, the point is to add functionality. To this end you have an Interface of which derives a Concrete class and a Wrapper interface. Then various wrappers will derive of Wrapper and you can chain them:
Interface* interface = new Wrapper2( new Wrapper1 ( new Concrete() ) );
Each wrapper add some functionality, whereas here we only have perfect forwarding... so it's not a Decorator.
The Composite pattern is different. Its goal is to hide whether you treat with a collection of elements or a single element. The usual example is a tree: you can apply operations either to an entire subtree or just a leaf node if it's implemented with a Composite Pattern.
Once more, there is not such thing here.
So my best guess is that you have either a wild design (perhaps a misguided attempt to emulate a well-known pattern) or you haven't given enough information (source code) for us to figure out the role. It seems strange anyway.
*Note: by self-recursion at class level I mean that an object of class A points to another object of class A, but this does not mean (certainly) that it points to the same instance... otherwise we would have a Stack Overflow (pun intended). This not the same instance bit is certainly worth checking during the SetImplementation call: note that any cyclic reference would cause death by recursion.
Matthieu M.
2010-03-03 08:28:34
I agree with "And I am afraid that you are looking at something that fails to emulate either of those."
Anders Abel
2010-03-03 08:39:58
@Matthieu: Any idea about the relationship between the ClassA and the ClassAFactory? Is this another design pattern?
jasonline
2010-03-03 09:14:23
@jasonline: the name suggest a `Factory` or perhaps an `AbstractFactory`, once again the term is heavily used without always strictly adhering to the pattern described by the Gang of Four. Without implementation it's difficult to say, and those `m_Impl` and `m_Interface` don't make more sense than for `ClassA`...
Matthieu M.
2010-03-03 16:23:47
A:
I'm not sure if this is a classic example of the pimpl idiom, but if so, the point is to separate the interface (which should be stable) from the implementation details (which you should be relatively free to change).
JohnMcG
2010-03-03 14:29:11