Re: Design Pattern Question: Why use Interfaces?
* Siegfried Heintze:
Here is the short version of my question: Why would one ever want to
create
a common ancestor that only consists of a pure virtual functions when you
can provide default implementions can be used by at least one (maybe more)
descendant?
A pure interface allows client code to access different implementations
of the interface without statically linking in implementation code.
Generally this is only meaningful when you expect at least two or more
different implementations. The cost is generally (1) duplicated
implementation code, and (2) with languages such as C++ and Java,
inability to express and enforce invariants, preconditions and
postconditions. In C++ the code duplication can sometimes be alleviated
by using multiple, virtual inheritance.
We are trying to abandon COM (we don't need COM and my team
leader hates anything that smells like Microsoft)
Silly. Either you need the functionality or not. If you don't need it,
then that's a good reason to not use it, but not using it because it's a
Microsoft technology is just dumb.
and we don't anticipate
ever using the proxy or bridge patterns.
Again, silly. But I think you mean that for the particular interface
you mention below, you don't expect it to ever be needed. Then that's a
good reason to not have it: premature abstraction is sometimes just as
bad as premature optimization.
As part of my refactoring effort, I have created a pure abstract ancestor
called ICommon consisting of approximately 80 pure virtual functions.
Both the name, which doesn't say anything, and the number of member
functions, indicate that this interface is a hodge-podge of unrelated
functionality, and should be split up and refactored.
Ask yourself what object state invariants it maintains and expects.
None? Then throw it to the flames.
At
this time, we have exactly one immediate descendant (from which I created
ICommon).
That immediate descendant probably needs refactoring. But in my
experience such monster classes typically indicate that the whole system
needs refactoring, i.e. the monstrosity is usually a consequence of
misguided design, which affects a lot of other classes. There's then
not much that can be done about the main problem while preserving the
old code, because it's a deep structural change that affects mostly
everything, but small critical aspects can be factored out, in an
incremental fashion (although this plays hell with estimates).
The thought of creating additional descendants from ICommon seems
daunting! My team leader says to get rid of ICommon because it serves no
purpose! Do you agree?
Yes. It is most probably the wrong solution to a non-problem.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]