help, my class is exploiding!

[Sacha]

I work on a rather large C++ project. The design, so far, seems to be
fine. However, there is one class, where the number of methods (and less
dramtically the number of members, too) is growing and growing. I
thought of different strategies to divert the glut into 'different
functional units', like

* through inheritance
* using member objects to encapsulate the methods of the parent object
* split the class without a parent class
* using array of function pointers (ugly, yes)
* merging some methods

but none of this seems to fit well into the design. As already
mentioned, I feel that the design is okay, it is simple too hard to keep
the overview. I know, this does not sound like a good design.

Think of a neat little box of hardware, which can be used as a phone,
pda, fax machine, tv, bar code reader, mp3 player, .... etc. It is a
perfectly fine object, because all works fine, and it is easy to control
the different capabilites, and it's even possible to send the a tv
screen shot as a fax. So the box is fine, but it has so darn many
connectors (tv line, phone line, audio in, audio out, ... ). Actually, I
like all these connectors, but it is so hard to keep the overview.

Back to the code: One idea I had, was to seperate the class declaration
into different files, but I don't know how to do this in a nice way.

Any ideas?

-Sacha

[Zara]

On Tue, 25 Oct 2005 10:20:55 +0200, Sacha <sa**********@unibas.ch>
wrote:

I work on a rather large C++ project. The design, so far, seems to be
fine. However, there is one class, where the number of methods (and less
dramtically the number of members, too) is growing and growing. I
thought of different strategies to divert the glut into 'different
functional units', like

* through inheritance
* using member objects to encapsulate the methods of the parent object
* split the class without a parent class
* using array of function pointers (ugly, yes)
* merging some methods

but none of this seems to fit well into the design. As already
mentioned, I feel that the design is okay, it is simple too hard to keep
the overview. I know, this does not sound like a good design.

Think of a neat little box of hardware, which can be used as a phone,
pda, fax machine, tv, bar code reader, mp3 player, .... etc. It is a
perfectly fine object, because all works fine, and it is easy to control
the different capabilites, and it's even possible to send the a tv
screen shot as a fax. So the box is fine, but it has so darn many
connectors (tv line, phone line, audio in, audio out, ... ). Actually, I
like all these connectors, but it is so hard to keep the overview.

Back to the code: One idea I had, was to seperate the class declaration
into different files, but I don't know how to do this in a nice way.

Any ideas?

-Sacha

Try to identify modular concepts and isolate them from others, thus
creating lots of lighter classes.

Break the class, and make it *only* a namespace. You may now break all
easily into different files. Once you have split the class into files,
you will find it is split more or less by concepts, each with its own
interface. Doesn't it sound like you may have lots of concrete
classes?

Best luck

[Sacha]

>

Try to identify modular concepts and isolate them from others, thus
creating lots of lighter classes.

Break the class, and make it *only* a namespace. You may now break all
easily into different files. Once you have split the class into files,
you will find it is split more or less by concepts, each with its own
interface. Doesn't it sound like you may have lots of concrete
classes?

Thanks for you answer. I have difficulties to separate it into different
concrete classes. They would be so thigtly bound, that there would be a
lot of overhead to let them interact. Somehow I feel, that I rather need
different namespaces withing the class (is this possible, at all?)

-Sacha

[TIT]

Sacha sade:

Try to identify modular concepts and isolate them from others, thus
creating lots of lighter classes.

Break the class, and make it *only* a namespace. You may now break all
easily into different files. Once you have split the class into files,
you will find it is split more or less by concepts, each with its own
interface. Doesn't it sound like you may have lots of concrete
classes?

Thanks for you answer. I have difficulties to separate it into different
concrete classes. They would be so thigtly bound, that there would be a
lot of overhead to let them interact. Somehow I feel, that I rather need
different namespaces withing the class (is this possible, at all?)

-Sacha

Well, depends on the functionality you need from namespaces. Ordinary
namespaces can't be put in classes but you could construct a similar
concept by yourself, although not nearly as powerful as one could
wish for:

#define NAMESPACE struct

class A {
NAMESPACE Exception {
class B {};
class C {};
};
A() {
throw Exception::B();
}
};

TIT

[Ferdi Smit]

Sacha wrote:

I work on a rather large C++ project. The design, so far, seems to be
fine. However, there is one class, where the number of methods (and less
dramtically the number of members, too) is growing and growing. I
thought of different strategies to divert the glut into 'different
functional units', like

* through inheritance
* using member objects to encapsulate the methods of the parent object
* split the class without a parent class
* using array of function pointers (ugly, yes)
* merging some methods

but none of this seems to fit well into the design. As already
mentioned, I feel that the design is okay, it is simple too hard to keep
the overview. I know, this does not sound like a good design.

Think of a neat little box of hardware, which can be used as a phone,
pda, fax machine, tv, bar code reader, mp3 player, .... etc. It is a
perfectly fine object, because all works fine, and it is easy to control
the different capabilites, and it's even possible to send the a tv
screen shot as a fax. So the box is fine, but it has so darn many
connectors (tv line, phone line, audio in, audio out, ... ). Actually, I
like all these connectors, but it is so hard to keep the overview.

Back to the code: One idea I had, was to seperate the class declaration
into different files, but I don't know how to do this in a nice way.

Any ideas?

Did you go through the Design Patterns book, and checked if any is
applicable to your specific situation? That often helps.

I'm thinking of splitting it in multiple, unrelated classes, and use
some sort of "glue" class to communicate. Pretty much like an iterator.
Only I can't tell if this is possible in your design, or even makes
sense... Perhaps give each partial 'box' a concept it models, and use
generic programming. When you speak of connectors, it makes sense to
have a seperate class for each of those subobjects having a connection
point. That way you can glue them together later on in any configuration
you'd like. Like Fax.in(Camera.out()); or something similar. I vaguely
recollect a design pattern doing just this, unfortunately I don't have
the book here atm.
--
Regards,

Ferdi Smit (M.Sc.)
Email: Fe********@cwi.nl
Room: C0.07 Phone: 4229
INS3 Visualization and 3D Interfaces
CWI Amsterdam, The Netherlands

[ben]

Sacha wrote:

I work on a rather large C++ project. The design, so far, seems to be
fine. However, there is one class, where the number of methods (and less
dramtically the number of members, too) is growing and growing. I
thought of different strategies to divert the glut into 'different
functional units', like

* through inheritance
* using member objects to encapsulate the methods of the parent object
* split the class without a parent class
* using array of function pointers (ugly, yes)
* merging some methods
The first step is to examine each non virtual member function (for
virtualy functions, question the virtuality) and ask:

1. Does this particular function have to access the class's private part?
2. Does this particular function conceptually reside in the class's
encapsulation boundary?

If the answer to 1 is no, consider making the function a non member, non
friend, standalone function, taking an extra parameter originally
occupied by the this pointer.

If the answer to both 1 and 2 is yes, then consider making the function
a non member, friend function, again, taking an extra parameter
originally occupied by the this pointer.

Ideally, you should select a smallest possible set of functions to be
member functions such that all other operations can be implemented
effectively and efficiently.

If after all these the member functions are still of large numbers, you
should consider if that class is taking too many responsibility.

but none of this seems to fit well into the design. As already
mentioned, I feel that the design is okay, it is simple too hard to keep
the overview. I know, this does not sound like a good design.

Think of a neat little box of hardware, which can be used as a phone,
pda, fax machine, tv, bar code reader, mp3 player, .... etc. It is a
perfectly fine object, because all works fine, and it is easy to control
the different capabilites, and it's even possible to send the a tv
screen shot as a fax. So the box is fine, but it has so darn many
connectors (tv line, phone line, audio in, audio out, ... ). Actually, I
like all these connectors, but it is so hard to keep the overview.
Have you considered multiple inheritance? The facets you gave (phone,
pda, fax, tv, etc) have individual functions with very little
overlaping, and this is exactly what multiple inheritance is designed
for. Again, bearing too many responsibilities is not a healthy idea.

Back to the code: One idea I had, was to seperate the class declaration
into different files, but I don't know how to do this in a nice way.
There are indeed many ways. If you have succeeded in making member
functions non members, you can now group these functions and put in
elsewhere than where the class is. An example of this approach is the
standard C++ library, take a look.

If you have succeeded in separating the class into multiple smaller
classes, it is also easy to put these smaller classes in logical forms.

Any ideas?

-Sacha

Ben

[Zara]

On Tue, 25 Oct 2005 11:09:03 +0200, Sacha <sa**********@unibas.ch>
wrote:

Try to identify modular concepts and isolate them from others, thus
creating lots of lighter classes.

Break the class, and make it *only* a namespace. You may now break all
easily into different files. Once you have split the class into files,
you will find it is split more or less by concepts, each with its own
interface. Doesn't it sound like you may have lots of concrete
classes?

Thanks for you answer. I have difficulties to separate it into different
concrete classes. They would be so thigtly bound, that there would be a
lot of overhead to let them interact. Somehow I feel, that I rather need
different namespaces withing the class (is this possible, at all?)

-Sacha

The only way to have different "namespaces" within a class is to have
private classes.

I should try first to disassemble the class, into separate data and
functions. Then group data with the classes that use them.

After that, a cautios analysis may help group data again in lighter
classes. Of course, it may be impossible.

But I feel that a class with a fat interface shoudl not be a class at
all, but just an interface within a namespace and a lot of data within
local anonymous namespaces.

[Sacha]

>

But I feel that a class with a fat interface shoudl not be a class at
all, but just an interface within a namespace and a lot of data within
local anonymous namespaces.

But I get difficulties if I need several objects (of the whole thing)
then, right?

-Sacha

[Alf P. Steinbach]

* Sacha:

I work on a rather large C++ project. The design, so far, seems to be
fine. However, there is one class, where the number of methods (and less
dramtically the number of members, too) is growing and growing.

There are a number of common anti-patterns that produce this effect, but which
one(s) you're up against is difficult to say.

It might be that the class has too many responsibilities: try to analyze what
it's responsible for, and whether responsibilities can be grouped in other
ways than one big heap. Then delegate/move groups of responsibilities.

It might be that the class is a symptom of procedural design. In that case, a
solution is to go object-oriented. First and foremost that means that where
you have functions that know what to do with a lot of types, they should be
replaced by objects that know what functions to invoke for their own types.

It might be that the class is the dreaded "spider" that sits in the middle of
everything. In that case it should be ditched. Small classes on the
periphery of the spider's net might be (partially) rescued, or not.

It might be that the problem is at the managerial level, e.g. a constant
stream of new requirements, or interaction with end-users/client forbidden.
Changing the behavior of bad management is futile. So in that case there's
little or nothing that you, as a project member, can do for this project.

Any way I don't think it is C++ related, i.e., it's off-topic in [clc++].

Follow-ups set to [comp.programming] because I'm too lazy to find an OO or
architectural or patterns group for you -- you should have done that.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Zara]

On Tue, 25 Oct 2005 12:03:17 +0200, Sacha <sa**********@unibas.ch>
wrote:

But I feel that a class with a fat interface shoudl not be a class at
all, but just an interface within a namespace and a lot of data within
local anonymous namespaces.

But I get difficulties if I need several objects (of the whole thing)
then, right?

-Sacha

Of course, if you need various objects of the same class, then you
can´t do it that way.

Still, my feeling is that no class should have a fat interface, so
this class should be disintegrated into atomic classes and after that,
reintegrated into a whole hierarchy. Probably you don´t need all
interface in all instances of the class, so you should look to create
various leaf classes to do the business.

Of course, all this is pure divagation, having no details of the fat
class.