Re: Testing Program Question
* Leigh Johnston:
Once you accept that abstract interfaces (which contain public pure
virtual
functions) are fine all bets are off and this rule of yours (and Herb's)
falls over.
Ignoring the fallacy of begging the question, it is totally
ignorant to claim that "abstract interface" == "*public* pure
virtual functions". Are you sure you want to make that claim?
Here is an abstract interface
class Foo
{
public :
void func ( ) { implFunc() ; }
protected :
virtual void implFunc ( ) = 0 ;
} ;
Notice there is no *public* pure virtual.
You know, really, do think it is that simple? Do think that
all these experts who have actually *thought* (as opposed to
just *felt*) about this topic forgot abstract bases? Do you
think all it takes if for Leigh to wave "abstract interfaces"
in their face and then all their reasoning just "falls over"?
Really man, get ahold of yourself. Don't be so vociferously
ignorant. At least learn about a topic before publicly
flailing and crying about it.
KHD
An abstract interface (or "callback class") is just that: an interface,
it never contains any code
Your statement would be correct for Java. In C++ this is not so. And indeed a
main issue that C++ folks have with Java is that restriction of Java interfaces.
so adding a non-virtual wrapper is both
retarded and pointless. A mixin class is different and sometimes it
might be necessary to change a public virtual to a non-virtual and live
with a temporary BC break.
Accepting a "temporary BC break" (whatever BC is meant to stand for, Binary
Compatibility?) is a small scale development view, if anything. In general the
work involved in fixing a problem increases exponentially with how late in the
development/maintainance process the problem is addressed. So it pays to detect
and fix problems as early as possible, and that's what e.g. pre- and post-
condition checking does: it detects problems as early as possible, to save work.
There are also other (context dependent) arguments against public virtuals, in
particular a clean separation of concerns, separating the public interface from
the details of implementation so that that implementation can be freely changed,
which again is mostly an issue with larger code sizes.
Note that the paragraph above cannot be understood with the restricted Java
meaning of "interface" where an interface "never contains any code".
Cheers & hth.,
- Alf