Re: c++ class design: where to put debug purpose utility class?
1230987za@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.
I have a strong feeling that this seemingly simple class is trying to do
way too much. I have this feeling because apparently, the obvious and
correct solution requires "quite a bit of setup". What kind of setup are
you talking about? Isn't the Item class already implemented (with all
the attendant tests?)
"path satisfies all the requirements" sounds like a function to me, one
that can and should be implemented independently of "addSearchPath".
#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.
Number 2 may not serve your purpose at all. It may be that the best
implementation is to get all the items out of a path when addSearchPath
is called and store a vector of *them* instead of storing a vector of
paths... or maybe some of the work should be done in addSearchPath,
while the rest is done in getAllItems. In other words, by testing the
implementation directly as you are proposing, you are also locking in
one particular implementation out of many. You are blowing encapsulation
out of the water.