Re: Packages and source files "physical" organization
Vincent ha scritto:
Hi all,
suppose I have to write a package X (I don't know if "package" is an
appropriate name). X is composed of N functions grouped into an
appropriated namespace:
namespace X {
int function1(...);
int function2(...);
...
int functionN(...);
}
X::function1(), X::function2(), ..., and X::functionN() in their
implementation "uses" objects of a class A:
class A {
... // a not trivial class
};
Objects of class A must be used *only* into X::function1(),
X::function2(), ..., and X::functionN(). To improve the encapsulation,
I don't want that A is visible outside X. In other words, class A is a
"private" part of package X.
How would you organize, from a "physical" point of view, the source
files of package X?
The "trivial" solution:
packageXDirectory/X.h <- X's interface
packageXDirectory/X.cpp <- X's implementation
packageXDirectory/A.h <- A's interface
packageXDirectory/A.cpp <- A's implementation
does not satisfy me, because don't makes clear the fact that A is
private.
Several Boost libraries use this organization, which seems good to me:
packageXDirectory/X.h <- X's interface
packageXDirectory/detail/A.h <- A's interface
moreover, class A is not defined in namespace X but in namespace
X::detail. I deliberately omitted the .cpp files from the picture
because Boost put them in a separate place, but you might as well decide
to keep them together with their respective .h files.
This won't make class A totally private, but at least the "detail::"
prefix is a good documentation that it's an implementation detail of
package X which should not be used directly.
And if function1()'s implementation requires a "private" function
functionY(), where you declare and implement functionY()?
Same as above. Create a "detail/functionY.h" file and declare
functionY() in namespace detail. If you have several small private
functions, you may group them in a single "detail/miscFunctions.h" file.
From a more general point of view, there are articles or books (other
than John Lakos's Large Scale C++ Design) that explain the use of
packages, modules, source file and directory organization?
Although I believe that Lakos' book is a very good book every serious
programmer should have read, I also believe it starts showing its age.
Unfortunately I don't know any good replacement for it.
HTH,
Ganesh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]