class XXX and class XXXImpl
-
I have seen people using this and I don't understand why or what is the main purpose. is it just to hide some implementations details to define such a new class (XXXimpl) and that the main one only servs to provide access to the interface functions ? Thank you in advance.
-
I have seen people using this and I don't understand why or what is the main purpose. is it just to hide some implementations details to define such a new class (XXXimpl) and that the main one only servs to provide access to the interface functions ? Thank you in advance.
I would suspect that what you are looking at is a case of having an abstract base class and a concrete implementation class. This is one of the most over abused uses of OO you can find. Basically what happens here is somebody creates a base class for something that they are only going to do once and then creates a concrete implementation of it. For some reason, they think this is going to aid them in reuse.
Deja View - the feeling that you've seen this post before.
-
I would suspect that what you are looking at is a case of having an abstract base class and a concrete implementation class. This is one of the most over abused uses of OO you can find. Basically what happens here is somebody creates a base class for something that they are only going to do once and then creates a concrete implementation of it. For some reason, they think this is going to aid them in reuse.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
For some reason, they think this is going to aid them in reuse.
:confused: You mean it doesn't?! :laugh: I'm not sure I'd go so far as to say that, but I would certainly say it's the result of people learning "just enough" about the OO concepts to be dangerous. Without actually understanding what the benefits are and both why and when to use them, people are destined to make mistakes and abuse the pattern.
Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[Forum Guidelines] [Articles] [Blog]
-
I have seen people using this and I don't understand why or what is the main purpose. is it just to hide some implementations details to define such a new class (XXXimpl) and that the main one only servs to provide access to the interface functions ? Thank you in advance.
There are probably lots of different motivations for this, but i'll describe my own: i want to hide the implementation details of a class from the rest of the system. For instance, i may only need a handful of public methods but scores of private methods, and wish to avoid clutter or allow changes without forcing clients to recompile. Or i might use types for data members that aren't used in the public interface at all, and by relegating them to the Impl class i reduce dependencies during compilation. Both of these become very important when distributing a C++ library in binary format, since they simplify the header files that need to be distributed along with the library (and the danger of a client becoming aware of, and relying on implementation-specific details that might not be preserved in a future release). The technique can also come in handy when building a simplified facade for some 3rd-party libraries, since it allows you to avoid leaking details of said libraries through to your clients.
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
-
There are probably lots of different motivations for this, but i'll describe my own: i want to hide the implementation details of a class from the rest of the system. For instance, i may only need a handful of public methods but scores of private methods, and wish to avoid clutter or allow changes without forcing clients to recompile. Or i might use types for data members that aren't used in the public interface at all, and by relegating them to the Impl class i reduce dependencies during compilation. Both of these become very important when distributing a C++ library in binary format, since they simplify the header files that need to be distributed along with the library (and the danger of a client becoming aware of, and relying on implementation-specific details that might not be preserved in a future release). The technique can also come in handy when building a simplified facade for some 3rd-party libraries, since it allows you to avoid leaking details of said libraries through to your clients.
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
Shog9 wrote:
i want to hide the implementation details of a class from the rest of the system. For instance, i may only need a handful of public methods but scores of private methods, and wish to avoid clutter
I agree with this as a possible reason for splitting up the implementation, but there are other ways to handle this in .NET with the use of the
partialkeyword.Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[Forum Guidelines] [Articles] [Blog]
-
Shog9 wrote:
i want to hide the implementation details of a class from the rest of the system. For instance, i may only need a handful of public methods but scores of private methods, and wish to avoid clutter
I agree with this as a possible reason for splitting up the implementation, but there are other ways to handle this in .NET with the use of the
partialkeyword.Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[Forum Guidelines] [Articles] [Blog]
Scott Dorman wrote:
there are other ways to handle this in .NET with the use of the partial keyword
AFAIK, that really only lets you split class definitions across source files, somewhat akin to using macros or
#includes in C++. The final, compiled type still contains everything. And since .NET doesn't use header files, you aren't really accomplishing anything by splitting up the source (well, you are, but nothing that matters to clients who shouldn't care about the source anyway). FWIW, Microsoft used the technique (usually by way of a public bare-bones type and a sealed, internal implementation) all over the place in the framework itself, often for no apparent reason (what, a MIME parser isn't generally useful?!). IMHO, it's a technique that should be used sparingly when at all.Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
-
Scott Dorman wrote:
there are other ways to handle this in .NET with the use of the partial keyword
AFAIK, that really only lets you split class definitions across source files, somewhat akin to using macros or
#includes in C++. The final, compiled type still contains everything. And since .NET doesn't use header files, you aren't really accomplishing anything by splitting up the source (well, you are, but nothing that matters to clients who shouldn't care about the source anyway). FWIW, Microsoft used the technique (usually by way of a public bare-bones type and a sealed, internal implementation) all over the place in the framework itself, often for no apparent reason (what, a MIME parser isn't generally useful?!). IMHO, it's a technique that should be used sparingly when at all.Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
You are correct, you can only split the definition up across source files not compiled binaries. Microsoft did use that technique in a lot of places within the framework, probably a hold-over from older habits.
Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[Forum Guidelines] [Articles] [Blog]
-
I would suspect that what you are looking at is a case of having an abstract base class and a concrete implementation class. This is one of the most over abused uses of OO you can find. Basically what happens here is somebody creates a base class for something that they are only going to do once and then creates a concrete implementation of it. For some reason, they think this is going to aid them in reuse.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
For some reason, they think this is going to aid them in reuse.
Probably the reason for this is because it does.
Steve
-
Pete O'Hanlon wrote:
For some reason, they think this is going to aid them in reuse.
Probably the reason for this is because it does.
Steve
thank you all for your precious interventions. indeed the recent example I found and which prompted me to post a question here was the MFC feature Pack. OK the source code is not written by Microsoft, but there was the new FrameWnd class along with another FrameImpl class, in separate files. the frame class holds an object of the Impl type,( and visversa I the Impl object holds a pointer to its corresponding Frame window object): at least for example you can notice the following : BOOL IsMenuBarAvailable () const { return m_Impl.GetMenuBar () != NULL; } this is a member function of the FrameWnd. not all members are encapsulated like this, and also some memebers are public visavis the consumer of the FrameWnd class.
-
You are correct, you can only split the definition up across source files not compiled binaries. Microsoft did use that technique in a lot of places within the framework, probably a hold-over from older habits.
Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[Forum Guidelines] [Articles] [Blog]
thank you all for your precious interventions. indeed the recent example I found and which prompted me to post a question here was the MFC feature Pack. OK the source code is not written by Microsoft, but there was the new FrameWnd class along with another FrameImpl class, in separate files. the frame class holds an object of the Impl type,( and visversa I the Impl object holds a pointer to its corresponding Frame window object): at least for example you can notice the following :
BOOL IsMenuBarAvailable () const
{
return m_Impl.GetMenuBar () != NULL;
}this is a member function of the FrameWnd. not all members are encapsulated like this, and also some memebers are public visavis the consumer of the FrameWnd class.
-
Pete O'Hanlon wrote:
For some reason, they think this is going to aid them in reuse.
Probably the reason for this is because it does.
Steve
Stephen Hewitt wrote:
Probably the reason for this is because it does.
You what? Why does separating a class out into an abstract and concrete implementation aid reuse? Read what I said and you'll find I'm talking about somebody splitting a class up into an abstract/concrete implementation where there is no need because it's never going to be reused. Sorry but there you go - reuse only applies if you have proper design.
Deja View - the feeling that you've seen this post before.
-
Stephen Hewitt wrote:
Probably the reason for this is because it does.
You what? Why does separating a class out into an abstract and concrete implementation aid reuse? Read what I said and you'll find I'm talking about somebody splitting a class up into an abstract/concrete implementation where there is no need because it's never going to be reused. Sorry but there you go - reuse only applies if you have proper design.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
Read what I said and you'll find I'm talking about somebody splitting a class up into an abstract/concrete implementation where there is no need because it's never going to be reused. Sorry but there you go - reuse only applies if you have proper design.
Yes but to be fair, you are making an assumption about the OP where there is no information suggesting this has occurred because, well there is no information at all about the project in the OP.
led mike
-
Pete O'Hanlon wrote:
Read what I said and you'll find I'm talking about somebody splitting a class up into an abstract/concrete implementation where there is no need because it's never going to be reused. Sorry but there you go - reuse only applies if you have proper design.
Yes but to be fair, you are making an assumption about the OP where there is no information suggesting this has occurred because, well there is no information at all about the project in the OP.
led mike
led mike wrote:
Yes but to be fair, you are making an assumption about the OP where there is no information suggesting this has occurred because, well there is no information at all about the project in the OP.
Actually, I was making a generalisation. Let's not get our assumptions confused with our generalisations - that way madness lies.
Deja View - the feeling that you've seen this post before.
-
led mike wrote:
Yes but to be fair, you are making an assumption about the OP where there is no information suggesting this has occurred because, well there is no information at all about the project in the OP.
Actually, I was making a generalisation. Let's not get our assumptions confused with our generalisations - that way madness lies.
Deja View - the feeling that you've seen this post before.
-
Scott Dorman wrote:
there are other ways to handle this in .NET with the use of the partial keyword
AFAIK, that really only lets you split class definitions across source files, somewhat akin to using macros or
#includes in C++. The final, compiled type still contains everything. And since .NET doesn't use header files, you aren't really accomplishing anything by splitting up the source (well, you are, but nothing that matters to clients who shouldn't care about the source anyway). FWIW, Microsoft used the technique (usually by way of a public bare-bones type and a sealed, internal implementation) all over the place in the framework itself, often for no apparent reason (what, a MIME parser isn't generally useful?!). IMHO, it's a technique that should be used sparingly when at all.Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
MS does things like that a lot to avoid supporting them. A MIME parser would be useful - but the one they have may be crap. Better to not give your clients a MIME parser at all, if you suspect its quality might be a bit suspect.
Mark Churchill Director Dunn & Churchill Free Download:
Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio. -
I would suspect that what you are looking at is a case of having an abstract base class and a concrete implementation class. This is one of the most over abused uses of OO you can find. Basically what happens here is somebody creates a base class for something that they are only going to do once and then creates a concrete implementation of it. For some reason, they think this is going to aid them in reuse.
Deja View - the feeling that you've seen this post before.
Yep, its a sister pattern to the far too common Foo/IFoo pairing.
Mark Churchill Director Dunn & Churchill Free Download:
Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.