|  | c++ class design: where to put debug purpose utility class? | | |
| | | S Perryman |  |
|  Posted: Tue Jul 01, 2008 7:08 am Post subject: Re: c++ class design: where to put debug purpose utility cla |  |
| |  | |
1230987za@gmail.com wrote:
| Quote: | Hi,
Here is more realistic capture of my problem, the original post is
over-simplified, but I do learn a lot from your guys' discussion,
class repo {
public:
repo();
/**
* Add one repo search path, if the path satisfies all the
requirements, this path will be stored internally.
*
* @returns 0 if succeeds
*/
int addSearchPath(string path);
/**
* Retrieve all the item from all the search paths
*/
std::vector<item> getAllItems();
private:
vector<string> pathList;
};
Given the above class, my unit test is to cover addSearchPath(), so
I can do either of the followings:
1. Just use the 2 public functions since they are the real API that
customer code will use.
2. Unit test code accesses the private data directly to verify
addSearchPath().
I guess James Kanze would suggest #1, but for my case I lean to #2.
The reason is unit test using #1 requires quite a bit setup for class
item while this unit test just want to test addSearchPath() does cover
all the requirements for a valid search path, so #1 seems to me too
much academic.
#2 serves my purpose very well and I do not want to add more API to
return the internal private data, I will use #define private public
trick.
Please throw your bricks.
|
#3 add a getPaths op.
Then you can define a post-condition for the addSearchPath op.
Regards,
Steven Perryman |
| |
| | | James Kanze | |
| | Posted: Tue Jul 01, 2008 7:54 am Post subject: Re: c++ class design: where to put debug purpose utility cla | |
| | | |
On Jun 30, 11:30 pm, ian-n...@hotmail.com wrote:
| Quote: | On Jul 1, 9:19 am, James Kanze <james.ka...@gmail.com> wrote:
Living where I do, however, I see enough of both
spellings that I don't actually notice which is being used (and
a lot of British programmers write "program", rather than
"programme" for a computer program). The above comment was
meant more as a hint, since I'm not sure how many Americans
would recognize gaol otherwise.
Ah, the joys of a common language. All the more reason to
express intent in something unambiguous like C++, or possibly
French.
|
French has Québecois, just like English has American (although
obviously, the influence of Québecois in the international
community is somewhat less than that of American). In fact, you
can be as precise, or as imprecise, as you want in French, just
as you can in English (or any other language I know). As you
want, or as you can---you'd be surprised at the number of
engineers who don't really master their native language, despite
what Dijkstra said: "Besides a mathematical inclination, an
exceptionally good mastery of one's native tongue is the most
vital asset of a competent programmer."
(http://www.cs.utexas.edu/users/EWD/ewd04xx/EWD498.PDF)
I think his point is somewhat related to the one I'm trying to
make: you have to have a very clear idea as to what the code is
supposed to do before you can write anything (test,
implementation or documentation). And IMHO, having a clear idea
means being able to express it in your native tongue, preferably
in writing.
| Quote: | Joking asside, how often do you see N programmers interpret a
written requirement in N different ways?
|
And how many times to you see written requirements which can
easily be interpreted in N different ways?
The first step is always to get a written requirement that
cannot be interpreted in N different ways, and to ensure that
all of the people working on the project are interpreting it in
the same way. I believe that this is what you are trying to do
with your tests, but I just don't believe that it's possible.
The expressivity (and the precision, when one has "an
exceptionally good mastery of one's native tongue) are orders of
magnitude higher in a human language; after all, it's been
evolving for centuries to reach a stage of perfection that
allows expression of all possible ideas, with as much precision
as desired (or as much ambiguity, if that's what is desired).
The real key, of course, is the mastery of the human language
being used. But my experience more or less coincides with that
of Dijkstra: those people who can't express themselves clearly
in their native language make a mess of the C++ as well. (And
of course, depending on the project, you might not be using your
native language. And while generally, the better you master
your native language, the better you can learn to master a
foreign language, and most truly competent programmers have no
trouble mastering another language, there are exceptions---I
have met one or two truly competent programmers who were
hopeless in foreign languages, despite being able to express
themselves perfectly in their own language.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
| |
| | | James Kanze | |
| | Posted: Tue Jul 01, 2008 8:08 am Post subject: Re: c++ class design: where to put debug purpose utility cla | |
| | | |
On Jul 1, 4:44 am, phlip <phlip2...@gmail.com> wrote:
| Quote: | Ian Collins wrote:
James Kanze wrote:
Phlip wrote:
That should map onto C++ classes -
Why? That's the first time I've heard that. (There are a lot
of cases where they do map onto C++ classes.)
Um, we agree again!
Unit tests (and many TDD tests) should target "units", which
are code elements that are clearly delimited and accessible to
inspection. Failure of a true Unit Test must implicate nothing
outside its target unit.
|
In an ideal world. In practice, of course, it's impossible. A
unit test may fail because of an error in the code its testing,
but it may also fail because of an error in the test itself, in
the test framework, in the framework used by the code it's
testing, in the compiler, in the OS, in the machine hardware...
(Hopefully, most of the time, we can safely assume that the
error is either in the code being tested or the test. At least
until proven otherwise. Although when I first started using C++
professionally, over half the errors detected by my unit tests
were due to errors in the compiler.)
| Quote: | Classes should also be clearly delimited and accessible to
inspection.
|
You'll have to define your terms better. Classes should
definitely be clearly delimited, and have rigorously defined
interfaces and behavior. So should units which aren't classes.
But what do you mean by "accessible to inspection"? Code
review? ("Inspection" seems to be a human activity here;
although some forms of inspection can be mechanized, surely none
to a sufficient degree to ensure quality in themselves.)
| Quote: | That does not mean units _must_ be classes. For example, if I
code-reviewed your unit test and said, "This is a bad test
because the unit it addresses is not one class," I have
brought nothing to the code review.
Most unit tests do indeed address classes, as a happy
coincidence. A pattern of _all_ the tests not focusing on
classes should raise a warning...
|
And now we're in agreement. Although I think it somewhat
depends: in a library of mathematical functions, there may not
be many classes, so tests will naturally not focus on classes.
But at least in the domains I'm active in, most "units"
correspond to a single class (and the second largest group,
albeit very much smaller, are units which consist of a very
small number of classes working very closely together).
| Quote: | Here's where we differ. The above assumes you have a design
which defines your classes.
I am so smart that I can heroically define all my classes in
my head before coding them. Etc...
|
And that I don't believe. I've never met anyone that brilliant.
[...]
| Quote: | I am not open to any braggadocio concocted rationales why what
we are doing is somehow vaingloriously wrong, and that all 7
guys are somehow too stupid and /fanfaron/ not to notice it.
|
The braggadocio is in the part I clipped. That you're all so
brilliant that you can do all the design work in your head,
think of all the test cases in a few days, without any written
support, etc. (Of course, it's a pretty small project, from
what you describe. But even then.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
| |
| | | S Perryman | |
| | Posted: Tue Jul 01, 2008 9:53 am Post subject: Re: c++ class design: where to put debug purpose utility cla | |
| | | |
Daniel T. wrote:
| Quote: | #3 add a getPaths op.
Then you can define a post-condition for the addSearchPath op.
Steve, that was an incredibly naive answer. The post-condition to
addSearchPath is, and should be, the effect it has on getAllItems.
|
If such a relationship can be established.
Can it done ?? And should it be done ??
| Quote: | Adding a getPaths function, or as others have suggested, just making
pathList public to the testing harness, fails to make that post-
condition testable.
|
FORALL np = SELF.getPaths() , op = OLD.getPaths() ,
d = difference(np,op) :
/* 1 */ d.size IN [0,1]
/* 2 */ (RESULT = 0) = ( (d = 1) AND d.contains(path) )
#1 states that either the set of paths changed or they did not.
#2 states (on the assumption that a duplicate path is considered an
error) that if the given path "satisfies all the requirements" , the
change to the paths set corresponds exactly to the given path.
What you failed to discern is that no obvious relationship appears to
exist between addSearchPath and getAllItems. Therefore a post-condition
using getAllItems cannot be defined.
OTOH there is a precise relationship between addSearchPath and the path
set. Therefore that is the better basis for a post-condition.
And if so inclined, a relationship between the path set and getAllItems
can probably be discerned (resulting in an invariant/post condition
thereof) .
| Quote: | The fact that he claims that such tests are difficult because it
"requires quite a bit of setup for class item" suggests to me that his
'item' abstraction is ill-defined, and or he needs another abstraction
"Path".
|
What became immediately obvious is that paths are the core concept
in the repo type, not items.
Which meant your claim :
"The post-condition to addSearchPath is, and should be, the effect it
has on getAllItems"
is somewhat naive.
Regards,
Steven Perryman |
| |
| | | Kai-Uwe Bux | |
| | Posted: Tue Jul 01, 2008 10:10 am Post subject: Re: c++ class design: where to put debug purpose utility cla | |
Daniel T. wrote:
| Quote: | OT:
Dijkstra said: "Besides a mathematical inclination, an exceptionally
good mastery of one's native tongue is the most vital asset of a
competent programmer." (http://www.cs.utexas.edu/users/EWD/ewd04xx/
EWD498.PDF)
The above is just too funny to pass up. Hand that sentence to an
English professor some time. He/she will enjoy the laugh. (I always
find it funny when someone [including myself] talks about how
important some particular skill is, while plainly demonstrating that
he/she doesn't have it. 
|
The above quote isn't Dutch, is it? So what does it show about Dijkstra's
command of his native language?
Best
Kai-Uwe Bux |
| |
| | | Alf P. Steinbach | |
| | Posted: Tue Jul 01, 2008 11:07 am Post subject: Re: c++ class design: where to put debug purpose utility cla | |
| | | |
* James Kanze:
| Quote: | On Jul 1, 1:27 pm, "Daniel T." <danie...@earthlink.net> wrote:
OT:
Dijkstra said: "Besides a mathematical inclination, an exceptionally
good mastery of one's native tongue is the most vital asset of a
competent programmer." (http://www.cs.utexas.edu/users/EWD/ewd04xx/
EWD498.PDF)
The above is just too funny to pass up. Hand that sentence to
an English professor some time. He/she will enjoy the laugh.
(I always find it funny when someone [including myself] talks
about how important some particular skill is, while plainly
demonstrating that he/she doesn't have it. :-)
I'm afraid I don't understand. To begin with, it looks like
very good English to me, and I don't see why an English
professor would find anything to say about it.
|
AOL.
What's wrong with it?
Cheers,
- Alf (revelling in off-topicality)
--
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? |
| |
| | | Daniel T. | |
| | Posted: Tue Jul 01, 2008 11:15 am Post subject: Re: c++ class design: where to put debug purpose utility cla | |
| | | |
On Jul 1, 5:08 am, S Perryman <q...@q.com> wrote:
| Quote: | 123098...@gmail.com wrote:
Here is more realistic capture of my problem, the original post is
over-simplified, but I do learn a lot from your guys' discussion,
class repo {
public:
repo();
/**
* Add one repo search path, if the path satisfies all the
requirements, this path will be stored internally.
*
* @returns 0 if succeeds
*/
int addSearchPath(string path);
/**
* Retrieve all the item from all the search paths
*/
std::vector<item> getAllItems();
private:
vector<string> pathList;
};
Given the above class, my unit test is to cover addSearchPath(), so
I can do either of the followings:
1. Just use the 2 public functions since they are the real API that
customer code will use.
2. Unit test code accesses the private data directly to verify
addSearchPath().
I guess James Kanze would suggest #1, but for my case I lean to #2.
The reason is unit test using #1 requires quite a bit setup for class
item while this unit test just want to test addSearchPath() does cover
all the requirements for a valid search path, so #1 seems to me too
much academic.
#2 serves my purpose very well and I do not want to add more API to
return the internal private data, I will use #define private public
trick.
Please throw your bricks.
#3 add a getPaths op.
Then you can define a post-condition for the addSearchPath op.
|
Steve, that was an incredibly naive answer. The post-condition to
addSearchPath is, and should be, the effect it has on getAllItems.
Adding a getPaths function, or as others have suggested, just making
pathList public to the testing harness, fails to make that post-
condition testable.
The tests the OP needs are something like:
repo r;
int result = r.addPath( "badpath" );
assert( result != 0 );
assert( r.getAllItems().size() == 0 );
---
repo r;
int result = r.addPath( "goodpath" );
assert( result == 0 );
assert( r.getAllItems().size() == expectedSize );
// examine the items in the container to make sure they are
// the expected ones.
---
etc...
The fact that he claims that such tests are difficult because it
"requires quite a bit of setup for class item" suggests to me that his
'item' abstraction is ill-defined, and or he needs another abstraction
"Path". |
| |
| | | Daniel T. | |
| | Posted: Tue Jul 01, 2008 11:27 am Post subject: Re: c++ class design: where to put debug purpose utility cla | |
OT:
Dijkstra said: "Besides a mathematical inclination, an exceptionally
good mastery of one's native tongue is the most vital asset of a
competent programmer." (http://www.cs.utexas.edu/users/EWD/ewd04xx/
EWD498.PDF)
The above is just too funny to pass up. Hand that sentence to an
English professor some time. He/she will enjoy the laugh. (I always
find it funny when someone [including myself] talks about how
important some particular skill is, while plainly demonstrating that
he/she doesn't have it. |
| |
| | | phlip | |
| | Posted: Tue Jul 01, 2008 11:38 am Post subject: Re: c++ class design: where to put debug purpose utility cla | |
| Quote: | Dijkstra said: "Besides a mathematical inclination, an exceptionally
good mastery of one's native tongue is the most vital asset of a
competent programmer." (http://www.cs.utexas.edu/users/EWD/ewd04xx/
EWD498.PDF)
The above is just too funny to pass up.
What's wrong with it?
|
ones native tongue
'one' is used as a pronoun, hence its possessive needs no apostrophe |
| |
| | | phlip | |
| | Posted: Tue Jul 01, 2008 12:08 pm Post subject: Re: c++ class design: where to put debug purpose utility cla | |
Christian Brunschen wrote:
| Quote: | ones native tongue
'one' is used as a pronoun, hence its possessive needs no apostrophe
"Edsger Wybe Dijkstra [ ... ] was a Dutch computer scientist."
So, English was not in fact his native language. So there is ... less
humor and/or irony involved than you appear to think.
|
Si! Major props to the D-man.
And, at work, we integrate so often, under the house-rule "always write a
distinct integration comment that you might need to read later" we have taken to
using slang, chat, LOLCAT, etc... |
| |
|
|
