class XXX and class XXXImpl
-
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.