Re: Gigantic Class
Immortal Nephi wrote:
I consider to use either object-based programming or object-oriental
programming. I am not sure to choose the correct programming
paradigms. I start with object-based programming because I need
encapsulation.
I provide client the interface. The client uses it to define object
in main() function body. They invoke object?s public member
functions. The object?s public member functions do the job to
process algorithm. All private member functions and implementation
details are hidden.
The base class is growing too big because I add more private member
functions. I debug and test them to be working properly. They are
less reusability. You will say that gigantic class is bad practice.
Why do you think that gigantic class is truly necessary?
I get quote from The ANSI / ISO C++ Professional Programmer?s
Handbook.
Gigantic class
There are no standardized methods for measuring the size of a class.
However, many small specialized classes are preferred to a bulky
single class that contains hundreds of member functions and data
members. But bulky classes do get written. Class std::string has a
fat interface of more than 100 member functions; clearly this is an
exception to the rule and, to be honest, many people consider this
to be a compromise between conflicting design approaches. Still,
ordinary programs rarely use all these members. More than once,
I?ve seen programmers extending a class with additional member
functions and data members instead of using more plausible
object-oriental techniques such as subclassing. As a rule, a class
that extends a 20-30 member function count is suspicious.
Gigantic classes are problematic for at least three reasons: users
of such classes rarely know how to use them properly, the
implementation and interface of such classes tend to undergo
extensive changes and bug-fixes; and they are not good candidates
for reuse because the fat interface and intricate implementation
details can fit rarely only a very limited usage. In a sense,
large classes are very similar to large functions.?they are
noncohesive and difficult to maintain.
[end of quote]
How do you solve to divide into hundreds of subclasses from one
giant class? Inheritance is the answer, but you write derive class
to use **some** or **all** inherited member functions. You don?t
want client to use all inherited member functions. They only need
to derive class through private inheritance.
For example:
class A
{
public:
A() : a( 1 ), b( 2 ) {}
~A() {}
protected:
int a;
int b;
};
class B : public A
{
public:
B() : c( 3 ), d( 4 ) {}
~B() {}
protected:
int c;
int d;
};
class C : public B
{
public:
C() : e( 5 ), f( 6 ) {}
~C() {}
protected:
int e;
int f;
};
class D : private C
{
public:
D() : g( 7 ), h( 8 ) {}
~D() {}
void Run()
{
a += 100;
b += 200;
c += 300;
d += 400;
e += 500;
f += 600;
g += 700;
h += 800;
}
protected:
int g;
int h;
};
class E : public D
{
public:
E() : i( 9 ), j( 10 ) {}
~E() {}
void Run()
{
D::Run();
i = 900;
j = 1000;
}
private:
int i;
int j;
};
int main()
{
E e; // object e is the interface
e.Run(); // Run() is available to client.
Return 0;
}
It is hard to reason about classes named A, B, and C, because that
makes it very abstract. A real class hierarchy usually is a model of
"something", where the structure of "something" often helps in
designing the model.
Most often it helps if a class does one thing, and one thing only. It
should do its "thing", and possibly maintain an internal state that it
might need (an invariant). Having protected data members breaks this,
as the class can no longer take responsibility for its own state.
Therefore protected data is very rarely used.
Unlike Java, in C++ there is generally no requirement for a single
base class. Using templates, all classes conforming to an interface
can be used as arguments to a function.
Bo Persson