Re: Enemy Functions?
I V wrote:
On Sat, 03 Jun 2006 20:32:24 -0400, Maxim Yegorushkin wrote:
Is not that function a member function in a derived class?
You can put all data members in a base class so that deirved
class member functions will not be able to access the data
members in the base class.
That seems like an excellent idea. In particular, it avoids
the problem that the practice suggested by Meyers makes the
format used to call a function dependent on the implementation
detail of whether or not that function has to access class
internals. I've tried in the past to avoid that problem by not
using member functions at all, instead using free functions
which are made friends where necessary, but that's so
unexpected as to be actively hostile to anyone reading the
code. Your approach pretty much avoids that problem. It's a
bit clunky to have to declare two classes, though,
particularly as you would have to write constructors in the
derived class to forward to each constructor of the base
class.
I think the real problem is to define the basic abstraction of
the class, and make it clear what that abstraction is. For
historical reasons, this is almost impossible for a standard
string class -- there are too many conflicting requirements.
But the string class is very much an exception in this. (My
original, pre-standard String class has exactly two member
functions: extract and replace. My idea was that everything
else could be expressed in terms of these two functions. Due to
user preasure, however, it grew to have one of the largest
interfaces in my library.)
Once you've defined this minimum abstraction, it becomes natural
to think in terms of global functions which operate on it.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]