Design question: accessor VS attribute

[Allerdyce.John]

I have a design type of quesiton.
What is the advantages of using accessor (a getter/setter method)
instead of making
the attribute 'public'?

If a class has public accessor (a getter/setter method) for its
attribute, why not just make the attribute 'public'? It requires less
code/typing. Or is there something I am missing?

Thank you.

[Dave Townsend]

<Al************ @gmail.com> wrote in message
news:11******** **************@ g47g2000cwa.goo glegroups.com.. .

I have a design type of quesiton.
What is the advantages of using accessor (a getter/setter method)
instead of making
the attribute 'public'?

If a class has public accessor (a getter/setter method) for its
attribute, why not just make the attribute 'public'? It requires less
code/typing. Or is there something I am missing?

Thank you.

If the setting of an attribute of an object causes a side effect, then the
setter method can
incorporate that side effect automatically. For instance, when I set the
color to red of a
"widget", I expect the widget to draw itself in red. Therefore we want to
NOT expose the
raw attributes to the user, but force him to use the setter method to
modify. Consequently,
we also need "getter" to access the internal values of attributes. Setters
can also check for
validity of the value, for instance if the attribute is an integer between
10 and 20, then if you
don't have a setter interface, some pinhead could set the value to -13.

It might be argued that if the attributes have no side effects, then it is
ok to access the attributes
directly. In this situation, objects owning these attributes are not very
interesting as they don't
have much behavior, so it is probably ok to expose their values public ( as
in the C-struct ).
( again, if you want to check the integrity of your data, then don't let
your clients change it
in an uncontrolled way).

Attributes may be be associated with an object, but may not have any
physical representation
on the object, for instance they may be calculated from other data or be
represented on another
object. For example, Volume of a box could be calculated from the box's
sides, but it would not
be good practice to store the value in addition to the sides. Similarly, if
you had a class "boxes"
which contained a number of separate boxes and volume being the volume of
the total of all
the boxes volumes, then this value could be computed on the fly when needed.
Hope that helps.

dave

[benben]

Al************@ gmail.com wrote:

I have a design type of quesiton.
What is the advantages of using accessor (a getter/setter method)
instead of making
the attribute 'public'?
Just to name a few benefits:
* Better encapsulating the member.
* Provide a gateway to modify the state of the object when it can't be
represented by a single member (for example, a database entry.)
* Provide a place for you to insert debug code to monitor all accesses
to the property.
* Provide "read only" or "write only" semantics;
* Provide data validating and/or adjusting.
* Can be provided in a form of overloaded operators (e.g.
vector<T>::oper ator[])

If a class has public accessor (a getter/setter method) for its
attribute, why not just make the attribute 'public'? It requires less
code/typing. Or is there something I am missing?
If the invariant of the class doesn't really care about that particular
member then you can expose it as a public member variable. Examples are
std::pair template (exposing members first and second,) 2D/3D vectors
(providing members x, y and z.)

If you are providing a getter and a setter for a particular member
without any code restricting the access you are exposing the member as
if it is being public. This is a good indicator that the member is not
part of what the class encapsulates and you may consider making it
public. However, if you ever have to change the class design in the
future and you don't want to break users' code relying on the member,
then you are better off with getter/setter.

Regards,
Ben

Thank you.

[Ian Collins]

Al************@ gmail.com wrote:

I have a design type of quesiton.
What is the advantages of using accessor (a getter/setter method)
instead of making
the attribute 'public'?

If a class has public accessor (a getter/setter method) for its
attribute, why not just make the attribute 'public'? It requires less
code/typing. Or is there something I am missing?

There was a thread (Style question: SetShutdown/GetShutdown .vs.
SetShutdown() overridden) last week that thrashed this subject.

--
Ian Collins.