Break class into smaller classes

[Immortal Nephi]

Please forgive me if my writing is not clear. English is not my
primary language. Hopefully, everyone can understand my writing.
I want to explain how C++ source code is hidden so clients do not
have to know the hidden source code. Let me show three different
clients.
Client A is C++ programmer. He designs general class. General class
can be video, keyboard, or mouse. Video class can have tens or
hundreds of member functions. Tens or hundreds of member functions
are hidden in the implementation. Interface in the video class is
built-in static or DLL library. Client B needs to know fewer member
functions such as interface's selectResolution(), showDisplay(), etc.
Client B is C++ programmer. He does not know client A’s hidden
source code. He only needs to know fewer member functions in the
video interface. He imports video library into his project. Also, he
can import mouse library, keyboard library, etc. He implements his
own design. He compiles and limks video interface, keyboard
interface, mouse interface, etc into complete software. The complete
software is available to client C.
Client C is not C++ programmer. He does not know neither client A’s
nor client B’s hidden design. He uses complete software for his daily
basis.
Let’s talk about client A. You said designed class with tens or
hundreds of member functions is flawed. Please explain why? One big
member function is flawed, but small member function is not. Hundreds
of member functions have fewer lines (1 to 20 lines). They are
carefully tested to be successful.
Client A put smaller hundreds of member functions together into fewer
big member functions. Fewer member functions become available to
client B. Client B only needs to execute public member functions.
They do not need to know complex hidden hundreds of member functions.
Please tell me more why it is not a good idea to have many member
functions in one big class. How can you suggest? Should big class
break into smaller classes? Why can’t you use smaller member
functions in one big class? What is worth C++ practice how to design
class in a better way?

 

[Pascal J. Bourguignon]

Please forgive me if my writing is not clear. English is not my
primary language. Hopefully, everyone can understand my writing.
I want to explain how C++ source code is hidden so clients do not
have to know the hidden source code. Let me show three different
clients.
Client A is C++ programmer. He designs general class. General class
can be video, keyboard, or mouse. Video class can have tens or
hundreds of member functions. Tens or hundreds of member functions
are hidden in the implementation. Interface in the video class is
built-in static or DLL library. Client B needs to know fewer member
functions such as interface's selectResolution(), showDisplay(), etc.
Client B is C++ programmer. He does not know client A’s hidden
source code. He only needs to know fewer member functions in the
video interface. He imports video library into his project. Also, he
can import mouse library, keyboard library, etc. He implements his
own design. He compiles and limks video interface, keyboard
interface, mouse interface, etc into complete software. The complete
software is available to client C.
Client C is not C++ programmer. He does not know neither client A’s
nor client B’s hidden design. He uses complete software for his daily
basis.
Let’s talk about client A. You said designed class with tens or
hundreds of member functions is flawed. Please explain why? One big
member function is flawed, but small member function is not. Hundreds
of member functions have fewer lines (1 to 20 lines). They are
carefully tested to be successful.

It's hundreds of _public_ member functions that are flawed.

There is no real system that have so many buttons. Imagine an
airplane cockpit: there is not a single keyboard with thousands of
buttons. What you find in a cockpit, is a lot of subsystems with
different and specific user interfaces.

This constraint comes from biology. Animal's short term memory is
limited. In the case of humans, short term memory can hold between 5
and 9 symbols. If you design a interface with more choices, then the
operator cannot keep all the choices in short term memory. Therefore
he is bound to make mistakes, forgetting a better option, and choosing
the wrong one.


Of course, the same applies to the body of the functions, if you go
over the short term memory capacity, the function won't be
understandable.

Notice also that there are various ways to abstract away a big number
of functions. If you have a lot of homogenous functions, you can
abstract them away as a familly of functions indexed: store the
functions in an array. Instead of having 100 different notions, now
you only have two: an array of function, and an index. If the
functions are not homogeneous they can probably be grouped by
categories. You may have functions dealing with some subsystem and
other with some other subsystem. Then you could reify these
subsystems, and move the methods to the relevant subsystem object.
Like in an airplane cockpit, you would ask the plane for a subsystem
(eg. the autopilot), and then ask the autopilot to activate or set its
route).


In anycase, this restriction is more about the public interface.
Internally if you need thousands of private methods, so be it. Of
course, if you have so much code, perhaps you should step back and
think about how to factorize things out so you may implement the
features with less code. But if the requirements really imply so much
code, no problem.

Client A put smaller hundreds of member functions together into fewer
big member functions. Fewer member functions become available to
client B.

If you mean the code of the functions, then no. You don't butcher
code like this. You have to do something meaningful, it's but a big
ball of mud.

Client B only needs to execute public member functions.
They do not need to know complex hidden hundreds of member functions.
Please tell me more why it is not a good idea to have many member
functions in one big class. How can you suggest?

See above.

Should big class
break into smaller classes?

Yes, that's a possibility. At least if you have a public interface
with so many public methods, it's probably a sign that you'd need to
break it down to smaller interface classes.

Why can’t you use smaller member
functions in one big class?

That has nothing to do with the number of public methods. Your bodies
should always be small, no matter what.

What is worth C++ practice how to design
class in a better way?

This is not related to C++. This is plain general design principle,
it goes even beyond computers, as the plane example above shows you.
Designing systems to be used by humans must take into account the
limitations of humans. If you designed a class to be used by an
artificial intelligence, you would have different constraints and you
could probably have larger public interfaces. But then, if there was
an AI able to use your class, it would probably be able to implement
it itself, so you'd be out of the loop anyways.

 

[Bart van Ingen Schenau]

Please forgive me if my writing is not clear. English is not my
primary language. Hopefully, everyone can understand my writing.
I want to explain how C++ source code is hidden so clients do not
have to know the hidden source code. Let me show three different
clients.
Client A is C++ programmer. He designs general class. General class
can be video, keyboard, or mouse. Video class can have tens or
hundreds of member functions. Tens or hundreds of member functions
are hidden in the implementation. Interface in the video class is
built-in static or DLL library. Client B needs to know fewer member
functions such as interface's selectResolution(), showDisplay(), etc. <snip
Let?s talk about client A. You said designed class with tens or
hundreds of member functions is flawed. Please explain why?

Because either none of those members does a complete job (client B needs
to call multiple members in a prescribed sequence to get something
useful done), or a large majority of the functions provide options that
nobody asked for and that nobody will ever use.

In the first case, those functions that do only half a job should be
removed from the interface and be replaced with a few functions that do
a complete job (perhaps calling those partial functions in their
implementation).
In the second case, the unused and unasked for functions should simply
be chucked out.

This link might also give some insights:
http://sourcemaking.com/antipatterns/swiss-army-knife

One big
member function is flawed, but small member function is not. Hundreds
of member functions have fewer lines (1 to 20 lines). They are
carefully tested to be successful.
Client A put smaller hundreds of member functions together into fewer
big member functions. Fewer member functions become available to
client B. Client B only needs to execute public member functions.
They do not need to know complex hidden hundreds of member functions.
Please tell me more why it is not a good idea to have many member
functions in one big class. How can you suggest? Should big class
break into smaller classes? Why can?t you use smaller member
functions in one big class? What is worth C++ practice how to design
class in a better way?

Please note that when we discuss class design, we only talk about what
the public (and possibly protected) interface exposes to the outside
world.
How many private members you use is not relevant to the design of the
class, as long as you keep to the principle that each and every function
has a single, unique purpose.

Bart v Ingen Schenau

 

[James Kanze]

Immortal Nephi wrote:
<snip

Because either none of those members does a complete job
(client B needs to call multiple members in a prescribed
sequence to get something useful done), or a large majority of
the functions provide options that nobody asked for and that
nobody will ever use.

In the first case, those functions that do only half a job
should be removed from the interface and be replaced with a
few functions that do a complete job (perhaps calling those
partial functions in their implementation). In the second
case, the unused and unasked for functions should simply be
chucked out.

Or perhaps the interface really should consist of several
different classes.

This link might also give some
insights:http://sourcemaking.com/antipatterns/swiss-army-knife

Please note that when we discuss class design, we only talk
about what the public (and possibly protected) interface
exposes to the outside world. How many private members you
use is not relevant to the design of the class, as long as you
keep to the principle that each and every function has a
single, unique purpose.

That's only true if the code never needs to be maintained. If
people have to understand it, then the implementation can't be
excessively complicated either. Regrouping the members into
smaller, implementation classes is an obvious solution.

 

[Jorgen Grahn]

Client A is C++ programmer. He designs general class. General class
can be video, keyboard, or mouse. Video class can have tens or
hundreds of member functions. Tens or hundreds of member functions
are hidden in the implementation. Interface in the video class is
built-in static or DLL library. Client B needs to know fewer member
functions such as interface's selectResolution(), showDisplay(), etc. ....
Please tell me more why it is not a good idea to have many member
functions in one big class. How can you suggest? Should big class
break into smaller classes? Why can?t you use smaller member
functions in one big class? What is worth C++ practice how to design
class in a better way?

Why don't you do it the other way around? Show us real, working C++
source code for class with hundreds of methods. It doesn't have to be
yours; the URL to some SourceForge project is enough. If noone can find
a good way to simplify that code, then you have proven that it is
sometimes a good idea.

A hypothetical "video" class which serves some unknown purpose, that's
hard to discuss.

/Jorgen