Naming convention for accessor methods (get/set)

[Generic Usenet Account]

A lot has been said in this newsgroup regarding the "evil" set/get
accessor methods. Arthur Riel, (of Vanguard Training), in his class,
"Heuristis for O-O Analysis & Design", says that there is almost never
an excuse for accessor methods. Personally, I do not go that far. I
do feel that they serve a useful purpose (albeit in a limited manner).
Personally I prefer dropping the "set" and "get" prefixes from the
method names altogether. For example:

class A
{
public:
...
int xyz() { return _xyz; } // instead of get_xyz()
void xyz(const int val) { _xyz = val; } // instead of get_xyz()
...

protected:
...
int _xyz;
...
};
This naming convention is also consistent with the IDL/C++ language
binding, and I wanted to seek your opinion regarding this.

Regards,
KP Bhat

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Kevin Goodsell]

Generic Usenet Account wrote:

A lot has been said in this newsgroup regarding the "evil" set/get
accessor methods. Arthur Riel, (of Vanguard Training), in his class,
"Heuristis for O-O Analysis & Design", says that there is almost never
an excuse for accessor methods. Personally, I do not go that far. I
do feel that they serve a useful purpose (albeit in a limited manner).
Personally I prefer dropping the "set" and "get" prefixes from the
method names altogether. For example:

class A
{
public:
...
int xyz() { return _xyz; } // instead of get_xyz()
void xyz(const int val) { _xyz = val; } // instead of get_xyz()
...

protected:
...
int _xyz;
...
};
This naming convention is also consistent with the IDL/C++ language
binding, and I wanted to seek your opinion regarding this.

(Cross-post to comp.lang.c++.m oderated removed. Cross-posting to
moderated groups slows down responses.)

My opinion:

I don't see a real problem with your naming scheme, but I wouldn't use
it personally. Overloaded functions are generally used when multiple
functions perform the same (or a similar) task using different
arguments. In this case, the functions do rather different things, so I
would prefer different names.

Set/get member functions aren't inherently bad, but some beginners get
the idea that they are a standard part of every class, which is
completely wrong. Most classes shouldn't have a need for typical set and
get functions (those that correspond to the actual data members in the
class). The interface should be separate from the representation
(obviously) so except in rather simple cases, you can't expect a
well-designed interface to correspond to the members used to represent
the class's state.

One last thing, I would recommend not using names that begin with an
underscore. It's OK in the context above, but there's a lot of cases
where it's not. The easiest way to avoid problems is to get in the habit
of never using identifiers (macros, variables, etc.) that begin with an
underscore.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Gianni Mariani]

Kevin Goodsell wrote:

Generic Usenet Account wrote: .... (Cross-post to comp.lang.c++.m oderated removed. Cross-posting to
moderated groups slows down responses.)

My opinion:

I don't see a real problem with your naming scheme, but I wouldn't use
it personally. Overloaded functions are generally used when multiple
functions perform the same (or a similar) task using different
arguments. In this case, the functions do rather different things, so I
would prefer different names.

Set/get member functions aren't inherently bad, but some beginners get
the idea that they are a standard part of every class, which is
completely wrong. Most classes shouldn't have a need for typical set and
get functions (those that correspond to the actual data members in the
class). The interface should be separate from the representation
(obviously) so except in rather simple cases, you can't expect a
well-designed interface to correspond to the members used to represent
the class's state.

One last thing, I would recommend not using names that begin with an
underscore. It's OK in the context above, but there's a lot of cases
where it's not. The easiest way to avoid problems is to get in the habit
of never using identifiers (macros, variables, etc.) that begin with an
underscore.

Opinion seconded.

[Samuel Krempp]

le Friday 19 September 2003 13:08, us****@sta.sams ung.com écrivit :

int xyz() { return _xyz; } // instead of get_xyz()
void xyz(const int val) { _xyz = val; } // instead of get_xyz()

There is one small factual inconvienence I can think of.
While you can do :

vector<A> v;
int x;
for_each(v.begi n(), v.end(), bind2nd(mem_fun _ref(&A::set_xy z), x) );

You need specific code to reach the overloaded 'xyz' membre function :

void (A::* pmf)(const int) = &A::xyz;
for_each(v.begi n(), v.end(), bind2nd(mem_fun _ref(pmf), x) );
oh, and it's easier to search for 'set_xyz' in a file. (the overloaded one
can be searched using a regexp like 'xyz([^)]*)' , it's not too complicated
either)

except for those details, I think it does'nt make much of a difference.

--
Samuel.Krempp
cout << "@" << "crans." << (is_spam ? "trucs.en.trop. " : "" )
<< "ens-cachan.fr" << endl;
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Le Chaud Lapin]

Gianni Mariani <gi*******@mari ani.ws> wrote in message news:<bk******* *@dispatch.conc entric.net>...

Kevin Goodsell wrote:

One last thing, I would recommend not using names that begin with an
underscore. It's OK in the context above, but there's a lot of cases
where it's not. The easiest way to avoid problems is to get in the habit
of never using identifiers (macros, variables, etc.) that begin with an
underscore.

Opinion seconded.

How about ending with underscore?

-Chaud Lapin-

[Kevin Goodsell]

Le Chaud Lapin wrote:

Gianni Mariani <gi*******@mari ani.ws> wrote in message news:<bk******* *@dispatch.conc entric.net>...

Kevin Goodsell wrote:

One last thing, I would recommend not using names that begin with an
underscore . It's OK in the context above, but there's a lot of cases
where it's not. The easiest way to avoid problems is to get in the habit
of never using identifiers (macros, variables, etc.) that begin with an
underscore .

Opinion seconded.

How about ending with underscore?

That's fine as long as it's not immediately preceded by another
underscore. Identifiers containing a sequence of two underscores are
also reserved (though I don't know what for off the top of my head). So
this:

identifier_

is OK. These are not:

_identifier (well, it's OK in some places)
_Identifier (pretty much never OK)
_IDENTIFIER (also never OK)
identifier__
__identifier
foo__bar

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Julián Albo]

Generic Usenet Account escribió:

Personally I prefer dropping the "set" and "get" prefixes from the
method names altogether. For example:
(snip)
This naming convention is also consistent with the IDL/C++ language
binding, and I wanted to seek your opinion regarding this.

In Spain we say: "aunque la mona se vista de seda, mona se queda". "A
monkey is a monkey even if dressed in silk" can be a translation. It is
the same thing wheter you use or not set and get prefixes. Personal
preference, as you say.

Regards.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Marcin Vorbrodt]

How about:

class A {
public:
int& EVIL() { return _evil; }
const int& EVIL() const { return _evil; }
};

This really is a horrible design... because you are exposing the underlying
implementation of your class. Which implies that if the implementation
changes, then the interface may need to be changed as well. That is more
evil than Sadam, Bin Laden, Stalin and Hitler put together. If you need to
be able to create setters and getters, why not just make the variable
public. If you need to have some other unrelated class access
private/protected elements of some other class, use friends instead. At
least you will not be breaking encapsulation.

GRRR

Martin
"Generic Usenet Account" <us****@sta.sam sung.com> wrote in message
news:90******** *************** *@posting.googl e.com...

A lot has been said in this newsgroup regarding the "evil" set/get
accessor methods. Arthur Riel, (of Vanguard Training), in his class,
"Heuristis for O-O Analysis & Design", says that there is almost never
an excuse for accessor methods. Personally, I do not go that far. I
do feel that they serve a useful purpose (albeit in a limited manner).
Personally I prefer dropping the "set" and "get" prefixes from the
method names altogether. For example:

class A
{
public:
...
int xyz() { return _xyz; } // instead of get_xyz()
void xyz(const int val) { _xyz = val; } // instead of get_xyz()
...

protected:
...
int _xyz;
...
};
This naming convention is also consistent with the IDL/C++ language
binding, and I wanted to seek your opinion regarding this.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Mike Wahler]

"Generic Usenet Account" <us****@sta.sam sung.com> wrote in message
news:90******** *************** *@posting.googl e.com...

A lot has been said in this newsgroup regarding the "evil" set/get
accessor methods. Arthur Riel, (of Vanguard Training), in his class,
"Heuristis for O-O Analysis & Design", says that there is almost never
an excuse for accessor methods. Personally, I do not go that far. I
do feel that they serve a useful purpose (albeit in a limited manner).
Personally I prefer dropping the "set" and "get" prefixes from the
method names altogether. For example:

class A
{
public:
...
int xyz() { return _xyz; } // instead of get_xyz()
void xyz(const int val) { _xyz = val; } // instead of get_xyz()
...

protected:
...
int _xyz;
...
};
This naming convention is also consistent with the IDL/C++ language
binding, and I wanted to seek your opinion regarding this.

I also prefer to overload a single meaningful name for this.

This is typically (but not always) feasible since one usually
takes an argument and the other does not. This form has worked
well for me so far.
-Mike

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[apm]

us****@sta.sams ung.com (Generic Usenet Account) wrote in message news:<90******* *************** **@posting.goog le.com>...

A lot has been said in this newsgroup regarding the "evil" set/get
accessor methods. Arthur Riel, (of Vanguard Training), in his class,
"Heuristis for O-O Analysis & Design", says that there is almost never
an excuse for accessor methods. Personally, I do not go that far. I
do feel that they serve a useful purpose (albeit in a limited manner).
Personally I prefer dropp

So do I. Here's why:

The Uniform Access Principle espoused by Betrand Meyer states that all
services offerd by a module should be available through a uniform
notation which does not betray whether they are implemented through
storage or through computation. Get get/set convention violates this.

-Andrew Marlow

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]