Managing large class heirarchies

[razael1]

Does anyone know of a good article dealing with organizing large class
heirarchies? I've always had trouble with circular dependencies,
global constants and variables, etc. Thanks.

 

[Phlip]

[cross-posted to comp.object]

Does anyone know of a good article dealing with organizing large class
heirarchies? I've always had trouble with circular dependencies,
global constants and variables, etc. Thanks.

Read /Refactoring/ by Martin Fowler. Then add unit tests to all your
behavior, and refactor until you don't have so much excess stuff.

Question: Why is your class hierarchy large? Most are very small. Your
incidental problems suggest that your hierarchy is causing trouble instead
of solving it.

Does every element of your hierarchy actually do something?

 

[iamfractal]

(e-mail address removed) skrev:

Does anyone know of a good article dealing with organizing large class
heirarchies? I've always had trouble with circular dependencies,
global constants and variables, etc. Thanks.

If you're using namespaces then, for one approach, browse:
http://www.edkirwan.kgbinternet.com/fracdoc/frac-page10.html

 

[red floyd]

(e-mail address removed) skrev:


If you're using namespaces then, for one approach, browse:
http://www.edkirwan.kgbinternet.com/fracdoc/frac-page10.html

My recommendation is not an article, but a dead-tree book:

"Large-Scale C++ Software Design" by John Lakos:

http://www.amazon.com/gp/product/0201633620/

 

[Victor Bazarov]

My recommendation is not an article, but a dead-tree book:

"Large-Scale C++ Software Design" by John Lakos:

http://www.amazon.com/gp/product/0201633620/

It's more than 10 years old! Things have changed a lot since then. He
should revise it heavily, if he can. Or other books should be recommended.
One of the good sources of info probably is 'comp.software-eng' newsgroup.
I am expressing caution here because there are other parts of this book
that should essentially be ignored, but they are not really marked as such
and it's not easy to recognize them.

V

 

[red floyd]

It's more than 10 years old! Things have changed a lot since then. He
should revise it heavily, if he can. Or other books should be recommended.
One of the good sources of info probably is 'comp.software-eng' newsgroup.
I am expressing caution here because there are other parts of this book
that should essentially be ignored, but they are not really marked as such
and it's not easy to recognize them.

Yes, it's 10 years old and pre-Standard, but from an organizational and
process point of view, it's still quite valid. The specifics of C++
have changed, but not the design, organizational, and process issues.

 

[Victor Bazarov]

Yes, it's 10 years old and pre-Standard, but from an organizational
and process point of view, it's still quite valid. The specifics of
C++ have changed, but not the design, organizational, and process
issues.

Actually they have. But it all has really nothing to do with C++...

V