Sutter's Pimples: Good, Bad, or Ugly?

[Phlip]

No effort is too great to eliminate unncessary dependencies. It wouldn't be
an exaggeration to say that gratuitous coupling is the software world's
biggest failing.

Lack of comprehensive, automated tests is the greatest failing. But
design-for-testing typically leads to much less coupling.

 

[Jeff Schwab]

Claudio Puviani wrote:




Lack of comprehensive, automated tests is the greatest failing. But
design-for-testing typically leads to much less coupling.

I sort of agree, but sort of disagree.

In my humble (really) opinion, the lack of provable correctness is the
greatest failing. Certainly testing is part of the process of proving
software correct; however, what is "correct" is a very sticky issue.
Even standards documents have defects.

I appreciate your zeal for testing, but automated tests will never
replace focussed tests. What I'd like to see is more use of coverage
metrics to establish correctness, with the highest feasible percentage
of the input and state space covered, and the remainder of possible
input/state combinations proved impossible (or correct) formally, e.g.
with symbolic logic.

 

[Daniel T.]

Martin doesn't mention Pimpl because it's not a goal, it's a temporary hack.
Don't write that which you must then retract.

I agreed with you whole heartedly up to this point. Pimpl is decidedly
not a hack, it is a standard idiom for handling a particular problem in
a particular language. I have no problem with your initial statement
that pimpl should be a refacoring meant to decrease compile times
without affecting the design of the program. Converting to an interface
*would* change the design of the program. Using an interface implies
that runtime polymorphism is necessary, but Pimple doesn't. Pimpl
simply, and completely, hides the implementation of a class by allowing
us to move *all* private elements to the cpp file.

 

[Claudio Puviani]

Lack of comprehensive, automated tests is the
greatest failing.

I'll assume here that you mean that the execution of the tests is automated
and not their generation. Still, I disagree. While it would be worthwhile to
have code that's both well-designed and rigorously tested, in practice, the
better code is designed, the more it's impervious to defects. Rigorous
testing of badly designed code is an amusing concept, particularly since
it's difficult to imagine someone without the ability to design code being
able to design meaningful tests.

But design-for-testing typically leads to much
less coupling.

John and I debated the point a few times and came to the conclusion that we
were basically saying the same thing. John's argument was that
design-for-testing leads to better overall design and I argued that good
overall design leads to better testability. The fact we both agreed on is
that they're one and the same, but testability can be used as an objective
litmus test.

Claudio Puviani

 

[Steven T. Hatton]

Phlip wrote:
[snip]

To anyone else who has followed this far: Both Lakos and Martin advise to
break a dependency cycle with an abstract bases class, even if there's no
other reason for one to exist.

A fully abstract base class seems like a lot of effort just to break a
dependency. Certainly there are many other reasons to use them, but I
don't think I would create one just for this.

Martin doesn't mention Pimpl because it's not a goal, it's a temporary
hack. Don't write that which you must then retract.

I don't see anything temporary (or hackish) about pimpl. Can you clarify?

-- Pete

I guess I don't understand why a fully abstract base class is that big of a
deal in comparison to the pimpl idiom. A fully abstract class is the
existing C++ analog to an interface in the two C++ knockoff languages. I'm
confident that's where the motivation came from. I am inclined to start
calling such a C++ animal an ABC Interface. But, perhaps I should sleep on
it. If performance is an issue with the virtual function call resolution,
can't that be addressed by using static pointers, etc.?