I
Immortal Nephi
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;
}
Do you see private inheritance? All data members and member
functions are inherited down to class C and all of them are
inaccessible in class D. All data members and member functions are
inherited down to class E from class D.
The client can use only class D’s data members and member functions
that are already inherited in class E.
My example above is object-based programming. All data members and
member functions are grouped in only one big class through
inheritance.
What if you are going to say? Use object-oriental programming
instead? Base class is the general and all derived classes are
specialized.
For example, base class is the CPU’s **ALL** instruction sets. It
has internal registers as data members and pure virtual member
function Dispatch(). Each derived class have specialized instruction
sets and Dispatch() implementation.
Why should each derived class be instanstized and data members are
inherited from base class? You only need one instance like I
described that giant class has one instance.
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;
}
Do you see private inheritance? All data members and member
functions are inherited down to class C and all of them are
inaccessible in class D. All data members and member functions are
inherited down to class E from class D.
The client can use only class D’s data members and member functions
that are already inherited in class E.
My example above is object-based programming. All data members and
member functions are grouped in only one big class through
inheritance.
What if you are going to say? Use object-oriental programming
instead? Base class is the general and all derived classes are
specialized.
For example, base class is the CPU’s **ALL** instruction sets. It
has internal registers as data members and pure virtual member
function Dispatch(). Each derived class have specialized instruction
sets and Dispatch() implementation.
Why should each derived class be instanstized and data members are
inherited from base class? You only need one instance like I
described that giant class has one instance.