Re: c++ class design: where to put debug purpose utility class?
On Jul 1, 7:53 am, S Perryman <q...@q.com> wrote:
Daniel T. wrote:
> > #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 ??
The OP requires that the relationship exist, so it should be done. He
has also said that testing the relationship is "difficult" though not
impossible.
OTOH there is a precise relationship between addSearchPath and the path
set. Therefore that is the better basis for a post-condition.
Given the interface of the repo class, there is no reason to require
that the path set be stored in any case. What matters is if
getAllItems returns the correct value, the pathList need not even
exist for getAllItems to work correctly. Testing the pathList, tests
the wrong thing.
> 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.
I agree that Path is a core concept that is being ignored by the OP.
Once we assume a Path type, the post-condition of addSeearchPath
becomes much easier to express:
addSearchPath(Path path);
post: getAllItems() includes old getAllItems() + path.getItems()
Which meant your claim :
"The post-condition to addSearchPath is, and should be, the effect it
has on getAllItems"
is somewhat naive.
No. The whole point of the addSearchPath method is to modify the
result returned by getAllItems, any post-condition or test that
doesn't express that is missing the point.