 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Maciej Sobczak
Guest
|
 Posted: Thu Mar 04, 2004 10:07 pm Post subject: Naming scheme for base and derived classes |
 |
|
Hi,
One of the shops is in the process of revising its policies and coding
standards.
One of the things that triggered most heated discussions was the idea of
enforcing the rule that the derived class name has to contain the name
of base class, or at least reference it in unambiguous way.
The example is:
class Export { ... };
class DBExport : public Export { ... };
class TextExport : public Export { ... };
The real focus is on "Is A" inheritance, since multiple inheritance and
non-"Is A" relations were excluded at the very beginning (traits,
policies, mix-ins, non-public inheritance, etc. are not considered).
What worries me is the perspective of using such rule *everywhere*, for
every "Is A" relationship.
Deep inheritance hierarchies come to mind as examples where such rule
can prove useless.
My personal position is that the name of the class (and anything else
for that matter) should be clear to the programmers. End of rule.
If the name can benefit from refering to the base functionality (like in
the example above), then it is OK and there is no need for a formal rule
to enforce it. Such a rule can introduce a lot of grief in cases where
names of classes are commonly understood in the given domain (Man ->
Human -> Mammal -> etc.) and the relations are obvious without name
decorations.
I would like to know whether you use some specific naming scheme for
inheritance and what is your experience with this scheme. Did it prove
useful in the long run? Do you have any suggestions?
Thank you very much,
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Gerhard Menzl
Guest
|
| Posted: Fri Mar 05, 2004 10:40 am Post subject: Re: Naming scheme for base and derived classes |
|
|
Maciej Sobczak wrote:
| Quote: | One of the things that triggered most heated discussions was the idea of
enforcing the rule that the derived class name has to contain the name
of base class, or at least reference it in unambiguous way.
The example is:
class Export { ... };
class DBExport : public Export { ... };
class TextExport : public Export { ... };
The real focus is on "Is A" inheritance, since multiple inheritance and
non-"Is A" relations were excluded at the very beginning (traits,
policies, mix-ins, non-public inheritance, etc. are not considered).
|
A reasonable guideline, but downright stupid as an absolute rule.
Counterexample off my cuff:
class Synchronizer {... };
class Mutex : public Synchronizer { ... };
class Semaphore : public Synchronizer { ... };
I am sure others will be able to come up with more examples.
Finding clear, descriptive names is a hard task that cannot be
accomplished with brains switched off.
Gerhard Menzl
--
Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Sat Mar 06, 2004 10:17 am Post subject: Re: Naming scheme for base and derived classes |
|
|
Gerhard Menzl <gerhard.menzl (AT) spambucket (DOT) net> writes:
| Quote: | Maciej Sobczak wrote:
One of the things that triggered most heated discussions was the
idea of enforcing the rule that the derived class name has to
contain the name of base class, or at least reference it in
unambiguous way.
The example is:
class Export { ... };
class DBExport : public Export { ... };
class TextExport : public Export { ... };
The real focus is on "Is A" inheritance, since multiple
inheritance and non-"Is A" relations were excluded at the very
beginning (traits, policies, mix-ins, non-public inheritance, etc.
are not considered).
A reasonable guideline, but downright stupid as an absolute rule.
Counterexample off my cuff:
class Synchronizer {... };
class Mutex : public Synchronizer { ... };
class Semaphore : public Synchronizer { ... };
I am sure others will be able to come up with more examples.
|
The most interesting one that comes to mind is Boot. Not only are
things like YachtBoot silly, but even in the cases where you do use the
word Boot, you would write Sailboot, and not SailBoot or Sail_Boot (or
whatever your naming convention requires for starting new words within a
symbol).
{I think James means 'boat' not 'boot'. -mod}
I'm tempted to say that it is almost an anti-pattern (although there are
exceptions). In general, the name of a type is an unqualified noun; a
qualified noun would be the name of an object.
I'm also curious if they have the same rule for Java. And require
ExportObject, DBExportObject, etc., because all classes derive from
Object.
And of course, what about multiple inheritance? That should give some
interesting names as well:-).
--
James Kanze mailto:kanze (AT) gabi-soft (DOT) fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
