Re: Gigantic Class
On Dec 27, 5:03 am, "Bo Persson" <b...@gmb.dk> wrote:
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.
Class A has all responsibility to handle private data members and
private member functions. Derived class B, C, and D do not make any
senses. You have no reason to inherit class A's private data members
to class B through additional new class A's public member functions.
I am like class A designer does not want clients to use inheritance
and they only need to define and use class A in their own function
body.
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.
I agree with you. Class A does only one thing. One thing has some
internal states. Some internal states are defined in private data
members inside class A. All private member functions maniuplate
internal states directly. Some private member functions are added in
public member functions and the client only needs to invoke public
member function.
The client is allowed to derive class from class A, but they are
denied if they attempt to inherit private data members into derived
class B because protected data is not defined.
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.
Sometimes, I do not need to add templates to class A. The client only
needs to use one data type such as int when they put arguments into
public member function's parameters. They can define one or more
class A objects in their function body. Also, they can use STL such
as vector. They put more class A objects in vector like five class A
objects in one array. The vector has template because class A is
defined user type.
For example:
int variable = 100;
A a1( variable );
A a2( variable + 1 );
A a3; // use default constructor as a3()
A oneArray[5];
vector < A > ( oneArray, 5 );
Make sense?