Re: Break class into smaller classes
On Jun 30, 12:46 pm, Bart van Ingen Schenau <b...@ingen.ddns.info>
wrote:
Immortal Nephi wrote:
<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.
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
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.
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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34