Sims wrote:
ronic wrote:
I read what you and others say but what about cases where the splitting of
files is more for ease of use rather than design.
For example imaging a data handling class.
You could split the class to make it easier to handle.
class SomeDataHandelingClass
{
#include "SomeDataHandelingClass_READ.h";
#include "SomeDataHandelingClass_WRITE.h";
#include "SomeDataHandelingClass_MISC.h";
};
Would that not be a case where splitting the class would make it somewhat
easier to read eventhouh the class might not be that big?
No. Your SomeDataHandelingClass.h file may be easier to read, but the
three sub-include files are definitely not. Those files won't be
self-contained and their interpretation will be dependent on something
external to them. How could they be easier to read?
The only case in which I consider splitting a class definition into two
(not more) include files is if I define a lot of inline functions. In
that case I may write:
class ClassWithInlineFunctions
{
// declaration of all members
};
// definition of all inline member functions
#include "ClassWithInlineFunctions.inl"
Notice that the file "ClassWithInlineFunctions.inl" would still be
self-contained (at least at the syntactic level) as the #include occurs
at global scope. Except for some namespace-wrapping techniques used to
solve compatibility issues with legacy code, putting an #include
anywhere except at global scope is pure evil.
Alberto
