Re: An kind of member function name scope specification
On Apr 27, 1:08 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
Ian Collins <ian-n...@hotmail.com> writes:
public:
Account( double const balance );
double balance(); };
No too big a deal here, but in general geters are a design
smell.
Yes, but I do not see a getter here. Let me explain why:
I have quoted the public interface of the class above.
It misses an important feature: documentation.
So I will add that document now in the way the names
suggest:
- The constructor initializes a new account with
an opening balance as the argument.
- The function =BBbalance=AB returns the current balance
of the account.
No mentioning of private fields in the documentation.
So a client/caller/reader of this interface can not know
whether this function returns the value of a private field
or obtains the balance using some other means. He does not
know which fields an object of this class has. Therefore, I
do not deem =BBbalance=AB to be a getter, just a non-void
function.
I wonder if both you and Ian aren't confusing design level and
implementation level a bit. From a design level, an Account
certainly "hasA" balance (or currentBalance, or whatever), and
that balance is a value, not a behavior. At the design level,
some classes really are just glorified data containers, some are
pure behavior, and some are a mixture of the two (although I
find the latter occur fairly rarely). At the design level, I
can't find anything to say against a class Account which
contains a function balance() (or getBalance(), depending on the
coding guidelines---but I prefer balance(), because it is
logically an attribute).
At the implementation level, of course, whether the class has a
private member, which the function simply returns, or does
something else, is irrelevant. (We use the function, rather
than a public data member, precisely to keep it irrelevant.)
I would see a getter, if the documentation would read
instead:
- Each object of this class has a field named =BBbalance_=AB.
The function =BBbalance=AB returns the value of this field.
Which is, precisely, an example of confounding an implementation
detail and a design aspect (in this case, the contract). The
class has an attribute balance. It may be implemented by a
single private variable, or not. But that's none of the client
code's business.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34