Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #7773 > unrolled thread

Reducing the number of classes

Back to article view | Back to comp.programming

Contents

  Reducing the number of classes Victor Porton <porton@narod.ru> - 2017-05-24 20:54 +0300
    Re: Reducing the number of classes Kaz Kylheku <686-678-9105@kylheku.com> - 2017-05-24 18:47 +0000

#7773 — Reducing the number of classes

What do you think on this?

Instead of having a base (abstract) class A and two its derived (concrete) 
classes B and C, I rewrite it as only B and C with B being a base of C. So, 
I decrease the number of classes from 3 to 2 but this maybe somehow 
"illogical" (should B be base of C or vice versa?)

-- 
Victor Porton - http://portonvictor.org

[toc] | [next] | [standalone]

#7774

On 2017-05-24, Victor Porton <porton@narod.ru> wrote:
> What do you think on this?
>
> Instead of having a base (abstract) class A and two its derived (concrete) 
> classes B and C, I rewrite it as only B and C with B being a base of C. So, 
> I decrease the number of classes from 3 to 2 but this maybe somehow 
> "illogical" (should B be base of C or vice versa?)

The question of whether C inherits from B is independent of the use of
the abstract base class A.

C can inherit from B, yet B can stick with the abstract A.

That allows some D to come along, and derive from A. (Even if there is
no such D later).

C should inherit form B if there is some tangible benefit.

If making C and B independent results in a lot of repeated code and data
declarations between B and C, using inheritance instead can collapse
those similarities, so that only the few different things in C
need to be coded specifically for C.

In programming languages in which abstract base classes are used, those
classes clarify what the interface is, and restrict clients to just
that interface. So there is a benefit.

If a client accesses the object through a reference to A, it can use
only A functions. B might have public functions which are not in A;
those won't be exposed to that client.

I'm not a big fan of these silly static OOP languages any more, but the
above is basicaly the synopsis of the ideology of abstract base classes
or "interfaces". In a nice, dynamic OOP language, we can treat two
classes as substitutable without declaring any inheritance from an
abstract base class or interface. Things just respond to the same
methods and that is that.

But that's just another reason why the question of how B is related to C
is independent of A. In a language in which a mechanism like A is not
commonly used, the comparison doesn't even arise. You either have
completely independent B and C which don't inherit anything in common
(or don't inherit anything *at all*), *yet are substitutable for each
other*, or else you use inheritance between B and C when you see that
most of the code is identical (and will likely stay identical in the
future).

About the last point; don't use inheritance if B and C are mostly
identical today, but C is actually a fork that is going to be changing
tomorrow. Know what I mean?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web