"Alex Blekhman" <tkfx.REMOVE@yahoo.com> wrote in message
news:uJZXAi$aJHA.1268@TK2MSFTNGP04.phx.gbl...
"Alec S." wrote:
Hmm, Im not sure where the component headers get included
though. They cant be included in Abstract.h since that would
create a cyclical dependency, but thats where they are used.
Considering your example it seems that you come from C# world. In
C++ (as opposite to C#) there is no such thing as partial class
definition. You need to declare the whole class at once (usually
in the .H file). Then you can implement (to define) its methods in
separate .CPP file(s). Each .CPP file must include the header file
with the declaration.
Actually I'm quite C++. That's why I am confused as to how to do this,
because I
have not seen any examples of it. I am however also from Assembler,
Pascal, and
batch files, so I am thinking of includes like I have done with those,
where the
included file is simply dropped in place, sort of like a #define or inline
function.
You can generalize what I am trying to do by forgetting about the other
stuff
and thinking of it as simply: I want to put a few of the class' methods
into
their own files by category. For example, declaring and defining all of a
class'
constructors as a group in their own H and CPP file, or all of a class'
accessor
functions together, etc.
Now, your class apparently suffers from the common problem of
being actually two or more classes. You can separate the methods
of CAbstract nto different .CPP files according to their use. But
what you really need to do is to refactor the CAbstract class
itself into smaller classes: CAbstract, CFoo, CBar, etc. So, each
class will represent one entity and will have one responsibility.
Yes, I have read of this problem several times before and considered that
it may
apply here. The thing is that the components are already their own things.
What
I am doing is to create a wrapper that allows accessing them all with the
same
few basic functions. A similar example is those database wrapper
interfaces (eg
Pear::MDB2, etc.) that allow you to access different databases (eg MySQL,
SQLite, DB2, etc.) with the same basic functions (eg connect(), query(),
etc.)
instead of db-specific functions (eg mysql_real_connect(), sqlite3_open(),
etc.)
Implement the private API in the base class. Implement a mix-in for each
public interface that translates the operations to calls to the private API.