 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Generic Usenet Account
Guest
|
 Posted: Fri Sep 19, 2003 11:08 am Post subject: Naming convention for accessor methods (get/set) |
 |
|
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++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Samuel Krempp
Guest
|
| Posted: Fri Sep 19, 2003 10:30 pm Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
le Friday 19 September 2003 13:08, [email]usenet (AT) sta (DOT) samsung.com[/email] écrivit :
| Quote: | 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.begin(), v.end(), bind2nd(mem_fun_ref(&A::set_xyz), x) );
You need specific code to reach the overloaded 'xyz' membre function :
void (A::* pmf)(const int) = &A::xyz;
for_each(v.begin(), 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++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Julián Albo
Guest
|
| Posted: Sat Sep 20, 2003 9:58 am Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
Generic Usenet Account escribió:
| Quote: | Personally I prefer dropping the "set" and "get" prefixes from the
method names altogether. For example:
|
(snip)
| Quote: | 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++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Marcin Vorbrodt
Guest
|
| Posted: Sat Sep 20, 2003 9:59 am Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
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" <usenet (AT) sta (DOT) samsung.com> wrote
| Quote: | 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++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Mike Wahler
Guest
|
| Posted: Sat Sep 20, 2003 10:02 am Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
"Generic Usenet Account" <usenet (AT) sta (DOT) samsung.com> wrote
| Quote: | 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++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
apm
Guest
|
| Posted: Sat Sep 20, 2003 3:10 pm Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
[email]usenet (AT) sta (DOT) samsung.com[/email] (Generic Usenet Account) wrote in message news:<90e5135.0309181203.cb6bee0 (AT) posting (DOT) google.com>...
| Quote: | 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++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Francis Glassborow
Guest
|
| Posted: Sat Sep 20, 2003 3:21 pm Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
In article <bkfe5j$mfp$1 (AT) uni00nw (DOT) unity.ncsu.edu>, Marcin Vorbrodt
<mvorbro (AT) eos (DOT) ncsu.edu> writes
| Quote: | 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.
|
But you snuck in return by reference which is a quite different issue.
Consider the following public interface for a class:
class point2d {
public:
// constructor:
explicit point2d(double xval=0, double yval=0);
// read access functions
double x()const;
double y()const;
double modulus()const;
double argument()const;
// write access functions
point2d & x(double xval);
point2d & y(double yval);
point2d & modulus(double mod);
point2d & argument(double degrees);
private:
// data choice irrelevant
};
Note that the user has no need to know how the data locating a point on
a plane is organised. However there is a great deal of benefit from
being able to select using Cartesian or Polar co-ordinates according to
what you are doing.
--
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
WW
Guest
|
| Posted: Sat Sep 20, 2003 10:48 pm Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
apm wrote:
| Quote: | usenet (AT) sta (DOT) samsung.com (Generic Usenet Account) wrote in message
news:<90e5135.0309181203.cb6bee0 (AT) posting (DOT) google.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.
|
Without going to quoting authority opinions and theories I would rather
tackle the problem from a T word point of view. A class (be it any class)
represents a concept in a problem domain. if that concept suport the
existence of things called getXxx setXxx then you should have them. If not,
you should not.
Furthermore a class is either just a representation of some simple storage
facility (in which case getters and setter might be appropriate) or it is
not. IMHO it is very very rare in real life design when you need such a
class. And if you feel you do, you really have to defend the idea, because
unless that class provides an adapter or facade to an exteranl storage
system they seem to have absolutely no function whatsoever.
Just let me give one example of a place where get/set might be appropriate
(as a name):
struct Radio {
xxx setVolume()...
xxx getVolume()...
private:
....
};
--
WW aka Attila
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Aaron Bentley
Guest
|
| Posted: Sun Sep 21, 2003 10:14 am Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
apm wrote:
| Quote: | 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.
|
At work, I have a PID object which represents a PID of the form
"abc-123456-wxyz". It has the following methods:
void Pid::setPrefix(const char[]) /* "abc" */
const char [] Pid::getPrefix() const
void Pid::setSuffix(const char[]) /* "wxyz" */
const char[] Pid::getSuffix() const
void Pid::setNumber(int) /* 123456 */
const char[] Pid::getSuffix()
void Pid::setPid(const char[]) /* "abc-123456-wxyz" */
const char[] Pid::getPid()
What's the implementation? Is the long string the autoritative version
with the getSuffix() and setSuffix() acting on part of it? Or is it
represented as two strings and a number? Or do I use one string for the
prefix AND suffix?
An object's interface is matter of taste. Too many accessors usually
spoil it, but too few make it hard to work with.
Aaron
--
Aaron Bentley
www.aaronbentley.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Ben Liddicott
Guest
|
| Posted: Sun Sep 21, 2003 6:47 pm Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
"Generic Usenet Account" <usenet (AT) sta (DOT) samsung.com> wrote
| Quote: | 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.
|
Accessor methods can become neccessary when you have several properties of a class which are really different views/transformations of the same underlying property. An example already given was polar vs. cartesian coordinates.
Here's another:
class P{
public:
// directory
std::string GetDirectory();
void PutDirectory(const std::string& newDir);
// filename = basename.extension
std::string GetFileName();
void PutFileName(const std::string& newFileName);
// full path
std::string GetFullPath();
void PutFullPath(const std::string& newPath);
// now add BaseName and Extension.
};
// example:
// this/is/the/directory/basename.extension
It may perfect sense to Get/Put any of these five properties independently; depending on what the program intends to do with the information. If it wants to create a sibling file, it can use GetDirectory. If it wants to name a known sibling file according to some convention, it might want to set the extension only. If it wants to name a companion file in a different folder, to set the directory, and so forth.
| Quote: | Personally I prefer dropping the "set" and "get" prefixes from the
method names altogether. For example:
|
(deleted)
| Quote: | This naming convention is also consistent with the IDL/C++ language
binding, and I wanted to seek your opinion regarding this.
|
You are talking about the CORBA IDL C++ language binding of course... as opposed to the many other IDL's, such as DCE/RPC, MIDL, MACH, Sun RPC and so forth.
It is time to invoke the concept of Least Surprise. If the code is intended or likely to be mixed with CORBA objects and calls, this would be a good convention to use. If it is intended or likely to be used together with with some other convention, you may wish to use that convention.
Personally I prefer Get/Put as prefixes, because one day you will need an indexed property.
class A{
public:
std::string GetValue(const std::string& name);
void PutValue(const std::string& name, const std::string& value);
};
Some times it is appropriate to use more than one convention:
class B{
public:
long get_Value(const std::string& name, std::string& value) throw();
long put_Value(const std::string& name, const std::string& value) throw();
std::string GetValue(const std::string& name) throw(MyException){
std::string tmp; long lErrCode = get_Value(name, tmp);
if(lErrCode)throw MyException(lErrCode);
return tmp;
}
void PutValue(const std::string& name, const std::string& value) throw(MyException){
long lErrCode = put_Value(name, value);
if(lErrCode)throw MyException(lErrCode);
}
};
This gives more flexibility to the user of the class. The verbosity and duplication involved mean that it is only really appropriate for very small or very stable libraries which are frequently used and thoroughly tested, or of course, for machine-generated code, for example from some sort of IDL.
--
Cheers,
Ben Liddicott
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Ed Avis
Guest
|
| Posted: Sun Sep 21, 2003 6:52 pm Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
[email]apm35 (AT) student (DOT) open.ac.uk[/email] (apm) writes:
| Quote: | 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.
|
Could you explain what you mean - it seems that wrapping everything in
get_x() and set_x() would indeed hide what was stored and what was
computed (though it's not clear what it means to call set_x() if x is
a computed value).
--
Ed Avis <ed (AT) membled (DOT) com>
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Ed Avis
Guest
|
| Posted: Sun Sep 21, 2003 6:53 pm Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
I believe Stroustrup favours the style of accessor where a single
overloaded function name is used for both getting and setting.
At least, ISTR seeing such a thing in the C++ book, and didn't see
any get_x() or set_x() methods.
--
Ed Avis <ed (AT) membled (DOT) com>
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Ed Avis
Guest
|
| Posted: Sun Sep 21, 2003 6:53 pm Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
"Marcin Vorbrodt" <mvorbro (AT) eos (DOT) ncsu.edu> writes:
| Quote: | 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.
|
It's not necessarily evil - for some concrete types it may be simplest
to expose the implementation. If a complex number has 'real' and
'imag', and you don't plan to change to polar coordinates later, you
might as well expose those rather than clutter the interface with
accessors. Especially so if you are writing this class for your own
use and can simply change all the callers in the unlikely event of the
implementation changing.
However if you are writing a class for 'complex number with magnitude
less than 1', then you wouldn't make the members public because it
would let a caller too easily break the class invariant.
| Quote: | If you need to be able to create setters and getters, why not just
make the variable public.
|
Indeed. The above code, however, may be preferred in shops where
coding standards mandate using accessors for all members and never
making them public. It's a way to simulate public visibility, in
cases where that would be the best design, while staying within the
letter of the religious law. (Of course, in such cases the accessors
would probably be called getEvil() or getMyEvil() or
pIGetMyEvilAsReference().)
--
Ed Avis <ed (AT) membled (DOT) com>
[ 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: Mon Sep 22, 2003 6:34 pm Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
[email]apm35 (AT) student (DOT) open.ac.uk[/email] (apm) writes:
| Quote: | usenet (AT) sta (DOT) samsung.com (Generic Usenet Account) wrote in message news:<90e5135.0309181203.cb6bee0 (AT) posting (DOT) google.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.
|
So do any of the alternatives in C++.
Or rather, none of them do, if used consistently. How does get and set
betray the underlying implementation?
--
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 |
|
|
Dave Harris
Guest
|
| Posted: Mon Sep 22, 2003 10:20 pm Post subject: Re: Naming convention for accessor methods (get/set) |
|
|
[email]mvorbro (AT) eos (DOT) ncsu.edu[/email] (Marcin Vorbrodt) wrote (abridged):
| Quote: | class A {
public:
int& EVIL() { return _evil; }
const int& EVIL() const { return _evil; }
};
This really is a horrible design... [...] If you need to be able
to create setters and getters, why not just make the variable
public.
|
There are degrees of encapsulation. Your interface at least allows
some indirection. For example:
int &EVIL() {
if (_pImpl == NULL)
_pImpl = new Impl;
return _pImpl->EVIL();
}
There is quite a lot of flexibility available. Eg if A has more than
one variable, we can use more than one Impl class and allocate them
at different times.
Reference-returning functions restrict the implementation less than
exposing an actual instance variable. Personally I avoid them (even
for things like vector::operator[]), but they are not evil.
-- Dave Harris, Nottingham, UK
[ 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
