Style question...

Thread view:

Steve Sobol - 03 Aug 2005 06:49 GMT

To paraphrase Shakespeare: "To bean or not to bean? That is the question."

If I have a class myClass

public class myClass {
public int myInteger;
}

where I want access to myInteger to be read/write, and will not need to use
reflection for any reason... is it better to create a getter and a setter
for myInteger and make it private, or is it acceptable to just leave it
public and not create any accessors?

I've been leaning towards making data private and providing accessors, but
it occurs to me that I've never asked which is the more commonly accepted
way to provide access. Perhaps there are Java classes that I could take that
would teach me the "right" way, but, well, I don't take classes - all my
programming skills are self-taught. :)

Signature

Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED
Company website: http://JustThe.net/
Personal blog, resume, portfolio: http://SteveSobol.com/
E: sjsobol@JustThe.net Snail: 22674 Motnocab Road, Apple Valley, CA 92307

Reply to this Message

Antti S. Brax - 03 Aug 2005 06:55 GMT

sjsobol@JustThe.net wrote in comp.lang.java.programmer:

> reflection for any reason... is it better to create a getter and a setter
> for myInteger and make it private, or is it acceptable to just leave it
> public and not create any accessors?

It is always better to use accessors. Maintainability and
consistency are some good reasons.

Signature

Antti S. Brax Rullalautailu pitää lapset poissa ladulta
http://www.iki.fi/asb/ http://www.cs.helsinki.fi/u/abrax/hlb/

[1385 messages expunged from folder "Spam"]

Reply to this Message

Thomas Hawtin - 03 Aug 2005 11:07 GMT

> sjsobol@JustThe.net wrote in comp.lang.java.programmer:
>
>>reflection for any reason... is it better to create a getter and a setter
>>for myInteger and make it private, or is it acceptable to just leave it
>>public and not create any accessors?

Rather than thinking setter/getter, you should be thinking what are the
operations that the interface of this class need to support. Don't put
the code away from the data. Getters and setters are an indication
(though not definite proof) that something is up with the design.

> It is always better to use accessors. Maintainability and
> consistency are some good reasons.

I'd permit non-private for Data Transfer Objects (DTO). Pretending to
encapsulate such an object is just daft.

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Thomas G. Marshall - 03 Aug 2005 21:51 GMT

Thomas Hawtin coughed up:

>> sjsobol@JustThe.net wrote in comp.lang.java.programmer:
>>
[quoted text clipped - 9 lines]
>> It is always better to use accessors. Maintainability and
>> consistency are some good reasons.

Multithreading safety. If the mutation/access of a member ever becomes a
compound operation, you will be creating something that breaks.

Furthermore, there are many things that may require that the value not be
mucked with during its own "atomic" operation. If you provide direct
access, you don't have a way to mutex.

> I'd permit non-private for Data Transfer Objects (DTO). Pretending to
> encapsulate such an object is just daft.

If an object exists to primarily hold data, then I'd have to agree. If an
object has behavior to any significant degree, then mutator/accessor is
preferred.

Signature

Sometimes life just sucks and then you live.

Reply to this Message

Steve Sobol - 03 Aug 2005 22:41 GMT

> Don't put
> the code away from the data.

I thought separating code from data is a basic OOP principle - or am I
misunderstanding your point?

Signature

Reply to this Message

Thomas Hawtin - 03 Aug 2005 23:55 GMT

>> Don't put the code away from the data.
>
> I thought separating code from data is a basic OOP principle - or am I
> misunderstanding your point?

Er, no. You have your data in an object all bound up with the methods
that operate upon it.

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Virgil Green - 04 Aug 2005 22:36 GMT

>> Don't put
>> the code away from the data.
>
> I thought separating code from data is a basic OOP principle - or am I
> misunderstanding your point?

Procedural code, yes; DML code, no.

Signature

Virgil

Reply to this Message

Monique Y. Mudama - 08 Aug 2005 20:04 GMT

> To paraphrase Shakespeare: "To bean or not to bean? That is the question."
>
[quoted text clipped - 14 lines]
> would teach me the "right" way, but, well, I don't take classes - all my
> programming skills are self-taught. :)

I agree that you should hide the data and only allow access through
methods. Here's how figure it: take the simple case of

public void setFoo (int foo)
{
myFoo = foo;
}

What if, later, you discover you need bounds checking? Or what if,
actually, it turns out that myFoo isn't even a value you want to keep
around, but rather the result of some calculations you do when
necessary?

If you always hide your data behind methods, you always have the
option of adding extra functionality or changing your underlying data
structure. If you don't, it gets a lot harder.

Signature

monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

Reply to this Message

Style question...

Free Magazines