|
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.
|
|
|
|
|
Pete O'Hanlon wrote: For some reason, they think this is going to aid them in reuse.
 You mean it doesn't?! 
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]
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Pete O'Hanlon wrote: Actually, I was making a generalisation
I won't argue since trying to re-read it while looking for the distinction is making me dizzy 
Pete O'Hanlon wrote: I would suspect that what you are looking at is a case of
led mike
|
|
|
|
|
Yep, its a sister pattern to the far too common Foo/IFoo pairing.
|
|
|
|
|
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 partial keyword.
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.'
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Hi to all,
This post is to claim for your wisdom and experience, I’m developing an application that provides certain standard functionalities: inventory management, orders, invoices, accounts receivable, etc. (I’ll call them core functionality) The problem here is that features solves the 90% of my customers requirements, BUT always need to make some customizations in order to fit each customer policies and special processes. So, the main challenge here is to design an architecture that allows me to make customer specific changes (most of the time they affect the database structure adding fields and/or tables, changing their corresponding UI’s for entering or viewing these new fields, adding validations, etc) without duplicating the core functionality, so if I made a fix or enhancement to the core functionality I’ll be able to distribute the changes to all my customers.
I hope I explained it clear, I already tried many alternatives but none likes me at all, hope any one can help me, I’m sure most of all ever have an scenario like this, when the customers says “all is great BUT it needs just some “little” changes to fit me 100%”. At this time I’m at design stage, so I’m wide open to fresh ideas.
Thanks in advance, regards
|
|
|
|
|
And here lies some of the worst and best designs ever inflicted on the user community (to say nothing of the poor bastards supporting the application)
In most cases I use an Item/Attribute structure as Product/Size Attribute/Measurement Attribute. This is all very well until you require discreet processing for a particular attribute type.
You are getting to the core of the OO design philosophies and you need a book no a library to cover the subject. trying to find a "correct/best" design is like picking the best beer or the correct indexing strategy.
Hopefully it will stimulate an interesting thread (or be completely ignored)
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
You're right, OO is supossed to solve these common challenges, and in theory it does, the problem comes when trying to get it into practice in a really complex system. Until now I solved using not OO techniques but tricks to parametrize the code, so I have all my customers speciall code in the same source and it's enabled or disabled at run-time. I know it's not an elegant or OO way, but it's the only way to reduce a little the maintenance.
What I'm looking for in this thread is to get some ones experience and different ideas to find an better OOper and elegant solution, hope that could happen
Regards
|
|
|
|
|
For an application like this OO concepts will only take you so far. Effectively what you are looking at building is an extensible framework that allows third-party customizations without the need to change code. Systems like this can be built but they are not trivial.
You need to start at the framework level and build your core framework in a very well structured way. Even though your core components are related to one another, I would build them as separate pieces as much as possible and provide the hooks necessary for them to interoperate. You also want to make sure that you have a robust data layer.
One approach that I have used in the past is to build things up in layers. I had a data layer that understood XML (and XML only). The data layer had the responsibility of parsing that XML and inserting data into the database and also taking data out of the database and putting it back into XML. My business objects were effectively specialized dictionaries.
The flexibility in the user interface is also going to be a challenge, although if you can guarantee that certain elements will always be there (and in the same layout) you can take advantage of the visual inheritance capabilities offered through Visual Studio. (This is nothing more than regular inheritance where your base class is a visually designable "thing" (like a form or user control). As long as that base class is not abstract you can visually design the derived class in VS just like you normally would.)
As for distribution of changes/fixes, you need to make sure everything is built in a very modular fashion (separate DLLs or assemblies for each component). That will allow you to update specific portions as needed.
If you want to go beyond this and actually implement a system that allows for this without code changes you need a lot more work and design as it will require publishing type services to update the database, which will also require conflict resolution to ensure that you don't remove user-made customizations with an update. From there the problem gets more complex as your business objects must be written in such a way as to be able to expose an unknown number of properties and metadata. The UI then needs to know how to render those objects in a completely dynamic fashion, with rules that govern how that layout works in the face of an unknown number of properties. All of that is possible, but definately not trivial.
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]
|
|
|
|
|
Hi Scott,
Thank you for your explanation, I think that's exactly what I'm looking for. But now I realize the challenges for creating an extensible framework, are much more than creating the core functionallity. The core should be aware of the possiblity to be extended, and also my business layer should be totally decoupled. I'm wondering I'll need to create a lot of interfaces or abstract classes to allow the interoperabilty between the different objects. In my system there is a lot of interaction between classes, they're tight coupled and I should separate them.
I guess I should create a prototype or look for some extisting model in order to evaluate if the effort in design and decoupling the objects worths it or if I should stay with my current model.
Thank you for your ideas!
Best Regards
|
|
|
|
|
ruben ruvalcaba wrote: think that's exactly what I'm looking for. But now I realize the challenges for creating an extensible framework, are much more than creating the core functionallity.
You're welcome. Yes, creating systems like this is possible but not simple. (I'm involved in building one at work now and it's been a very long road and a lot of work involved.)
ruben ruvalcaba wrote: I'm wondering I'll need to create a lot of interfaces or abstract classes to allow the interoperabilty between the different objects
We are doing things with a combination of interfaces, abstract classes, and generics from the framework layers.
ruben ruvalcaba wrote: In my system there is a lot of interaction between classes, they're tight coupled and I should separate them.
You should look at doing this no matter what. The more tightly coupled your objects are the harder they become to maintain. Generally you want a loosely coupled but highly cohesive system. (http://en.wikipedia.org/wiki/Coupling_(computer_science)[^]).
In the long run, making sure you have a solid and well-thought-out architecture is always worth it as it leads to code that is more easily maintained and extended in the future. It all depends on where you want to spend your time/effort/money - up front in the design or afterwards in the maintenance phase.
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]
|
|
|
|
|
My users need to be able to specify their own formatting preferences for string output.
So, either in Settings or the database or wherever, they specify a format string: "%lastName% can be reaced at %mainPhone% or %email%" to control the output of this class:
class Person
{
string nameFirst;
string nameLast;
string eMail;
List<Phone> phones;
}
(which is strictly by example - the real object network will be much larger/complicated)(and tokenizing the format string is no problem for me)
I'm wondering how to best produce the final string at runtime in a reasonably efficient manor. It's doubtful there will be more than a few hundred of these items at a time (less than a dozen most likely) and this string will be produced for tooltips, columns in grids, reports, etc. Still - while I don't have to worry about this being executed 1,000 a second - I'd like for it not to be too much of a pig. Maintainability is more of a concern.
It seems to me this is a good use for codeDOM and generating a dynamic method. When the app is loaded, it reads the configuration string and generates a method that looks
string DisplayAs()
{
string fmt = "{0} can be reached at {1} or {2}";
string[] args = { nameLast, SomeMethodThatKnowsHowToDetermin_MAIN_PhoneFromList(), eMail };
return string.Format ( fmt, args );
}
I've never used the codeDOM but I think I can manage something like this. But is this overkill or maybe there's a better way?
I could take a brute force approach and loop through whatever format string the user supplies doing string substitutions based on my list of 'keywords' (i.e. %mainPhone%) but there could easily be a dozen or so of those keywords. That seems painfully inefficient to me - but maybe not to the extent I should worry about it.
Thanks,
Dan Holt
|
|
|
|
|
HoltDan wrote: But is this overkill or maybe there's a better way?
Well it does seem overkill since string.Format(...) will do the trick.
However I am wondering about the larger problem of letting users supply things like format strings. How do they test them, debug them and what mechanisms to you use to guard against runtime errors like mismatching arguments?
led mike
|
|
|
|
|
I guess I could take their input string ("%A% something %M% - %B% @ %T%" - or whatever) and transform it into a format string "{0} something {1} - {2} @ {3}" and load up a list of delegates to return the corresponding args. Kind of like what I'd do preparing to generate the dynamic method in my original example. However, I'd still have to do it per-instance or per-invocation of the method that calls string.Format.
I just don't have a good feel for how efficient something like that is. Plus I'll probably never get the chance to measure in any meaningful context.
Or maybe I'm being dense and there's a design pattern or technique for doing this sort of thing. I looked into IFormatProvider(?) which might be helpful once the code gets down to the nuts 'n bolts of formatting each piece of text, but not in assembling the parameters at run time.
The error handling isn't much of a concern. I simplified the example: in reality, this product gets installed at various customer sites and configuring the display strings to their specifications is something that will be part of the setup. There will be error checking and it will be done infrequently and then by 'qualified' professionals (that's a good one!).
Dan
|
|
|
|
|
HoltDan wrote: The error handling isn't much of a concern.
Ok, good luck
led mike
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
