Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > A question about some long java code that has getters/setters

Reply
Thread Tools

A question about some long java code that has getters/setters

 
 
markspace
Guest
Posts: n/a
 
      07-25-2011
On 7/25/2011 1:27 PM, Patrick May wrote:
> With the exception of cases like DAOs, getters
> should be very rare and setters non-existent.



I think perhaps you meant "DTO" here.

 
Reply With Quote
 
 
 
 
lewbloch
Guest
Posts: n/a
 
      07-25-2011
On Jul 25, 1:27*pm, Patrick May <(E-Mail Removed)> wrote:
> lewbloch <(E-Mail Removed)> writes:
> > It is standard practice to create accessors and mutators for class
> > attributes. *There's nothing wrong with that.

>
> * * *Actually, there is. *It encourages a style of programming where
> objects have too much knowledge about each other. *Encapsulation is
> important; objects should ask each other for services, not manipulate
> each others internals. *With the exception of cases like DAOs, getters
> should be very rare and setters non-existent.


You don't create them for hidden members! Yeesh.

By definition the attributes are those that you want to make public.

What you choose to make public should be a matter of design, not
dogma. I do not endorse making attributes public that shouldn't be.

--
Lew
 
Reply With Quote
 
 
 
 
markspace
Guest
Posts: n/a
 
      07-25-2011
On 7/25/2011 1:27 PM, Patrick May wrote:
> It encourages a style of programming where
> objects have too much knowledge about each other.



This is an interesting idea. However, I think it might be short
sighted, or at least incomplete.

For example, I've just been working on a project which involves sending
commands over a network. There are up to four parameters for all
commands, and it might be better style to perhaps only create some
number of constructors which only allow valid combinations of these four
parameters.

However, I went instead with the "natural" mutator approach. First,
supplying a constructor or method for each possible combination would
result in a large number of constructors or methods, vs. the simplicity
of just four mutators.

Second the internal state of the object is not so hard to grasp that the
mutators are hard to use. It's pretty easy and basic to set the
parameters you want and then ship the command across the network.

And last, large numbers of arguments can be difficult to work with.
Users don't always remember the correct order, and swaping two
parameters inadvertently is a hazard. Harder to do that with just a
single parameter, and easier to spot an error in a code review.

So, yes I think you have a point that mutators shouldn't be used in
every case. But I think there's a rather large numbers of cases where
they do work, and are best practice.


 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      07-26-2011
markspace <-@.> writes:
>On 7/25/2011 1:27 PM, Patrick May wrote:
>>It encourages a style of programming where
>>objects have too much knowledge about each other.

>This is an interesting idea.


I would not call an »interesting idea«, what is the
common standard of object-oriented programming teaching.
Obviously, Getters and Setters break encapsulation.

To be specific, there are classic articles such as

http://www.javaworld.com/javaworld/j...5-toolbox.html

or

http://c2.com/cgi/wiki?AccessorsAreEvil

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      07-26-2011
On 7/25/2011 8:00 PM, Patricia Shanahan wrote:
> On 7/25/2011 3:56 PM, lewbloch wrote:
>> On Jul 25, 1:27 pm, Patrick May<(E-Mail Removed)> wrote:
>>> lewbloch<(E-Mail Removed)> writes:
>>>> It is standard practice to create accessors and mutators for class
>>>> attributes. There's nothing wrong with that.
>>>
>>> Actually, there is. It encourages a style of programming where
>>> objects have too much knowledge about each other. Encapsulation is
>>> important; objects should ask each other for services, not manipulate
>>> each others internals. With the exception of cases like DAOs, getters
>>> should be very rare and setters non-existent.

>>
>> You don't create them for hidden members! Yeesh.

>
> I've been doing some Java tutoring. I've seen coursework assignments
> that *required* the student to create a getter and setter for every
> field.


No problem: Make all the getters and setters `private'.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      07-26-2011
On 26 Jul 2011 00:42:20 GMT, http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram)
wrote:

>markspace <-@.> writes:
>>On 7/25/2011 1:27 PM, Patrick May wrote:
>>>It encourages a style of programming where
>>>objects have too much knowledge about each other.

>>This is an interesting idea.

>
> I would not call an »interesting idea«, what is the
> common standard of object-oriented programming teaching.
> Obviously, Getters and Setters break encapsulation.


Getters: yes. Setters: maybe.

What is wrong with something like:

FilePrinter r=new FilePrinter();

// General Options
r.SetPrinter("\\Boojum");
r.SetCopies(1);
r.SetDoubleSided(true);

r.SetFilename("c:\somedir\fileone");
r.Print();

r.SetFilename("c:\somedir\filetwo");
r.Print();

r.SetFilename("c:\somedir\filethree");
r.SetCopies(5);
r.Print();

[snip]

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      07-26-2011
On 7/25/2011 7:50 PM, markspace wrote:
> On 7/25/2011 1:27 PM, Patrick May wrote:
>> It encourages a style of programming where
>> objects have too much knowledge about each other.

>
>
> This is an interesting idea. However, I think it might be short sighted,
> or at least incomplete.
>
> For example, I've just been working on a project which involves sending
> commands over a network. There are up to four parameters for all
> commands, and it might be better style to perhaps only create some
> number of constructors which only allow valid combinations of these four
> parameters.
>[... uses "vanilla" constructor plus mutators ...]


Another approach -- which may or may not make sense in your
situation, but might be worthy of consideration -- is to make Command
immutable, with one constructor that takes a single argument of the
mutable CommandBuilder class.

public class Command {
private final int tweedeldum;
private final Control[] tweedledee;
...
public Command(CommandBuilder builder) {
if (builder.isValid()) {
tweedledum = builder.tweedledum;
tweedledee = builder.tweedeldee.clone();
...
} else {
throw new IllegalArgumentException(
builder.toString());
}
}
}

public class CommandBuilder {
private int tweedledee = 42;
private Control[] tweedledum = new Control[0];
...
public CommandBuilder setTweedledee(int tweedledee) {
this.tweedledee = tweedledee;
return this;
}
public CommandBuilder setTweedledum(Control[] tweedledum) {
this.tweedledum = tweedledum;
return this;
}
...
}

...

Command makeItSo = new Command(
new CommandBuilder().setTweedledee(97));
Command avastYeScurvySpalpeens = new Command(
new CommandBuilder().setTweedledum(getControls())
.setTweedledee(-86));

True, the validation and exception-throwing still happen at
run-time -- but it happens at Command construction, instead of later
on when the Command is used and the source of the bad parameters may
be more of a mystery.

--
Eric Sosman
(E-Mail Removed)d
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      07-26-2011
Gene Wirchenko <(E-Mail Removed)> writes:
>>I would not call an »interesting idea«, what is the
>>common standard of object-oriented programming teaching.
>>Obviously, Getters and Setters break encapsulation.

>Getters: yes. Setters: maybe.
>What is wrong with something like:
>FilePrinter r=new FilePrinter();
>// General Options
>r.SetPrinter("\\Boojum");
>r.SetCopies(1);
>r.SetDoubleSided(true);


Before I can answer this, I need to know, whether there are
setters in the code above. How do you define »setter«? Is a
»setter« any one-argument method, whose name begins with »Set«?

(To apply my own definition, I would need to see the
documentation of a method, to judge whether it is a »setter«.)

 
Reply With Quote
 
Jukka Lahtinen
Guest
Posts: n/a
 
      07-26-2011
lewbloch <(E-Mail Removed)> writes:
> Chad wrote:
>> The following code, which is taken from one of my school books,


> Really, don't use this book. Get a good book.


I don't argue about that, but..
TOP told us it's a school book. When at school, were you allowed to
choose the books yourself?

OTOH, it would probably be a good idea to point the faults out to the
teacher.

--
Jukka Lahtinen
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      07-26-2011
On 11-07-25 09:42 PM, Stefan Ram wrote:
> markspace <-@.> writes:
>> On 7/25/2011 1:27 PM, Patrick May wrote:
>>> It encourages a style of programming where
>>> objects have too much knowledge about each other.

>> This is an interesting idea.

>
> I would not call an »interesting idea«, what is the
> common standard of object-oriented programming teaching.
> Obviously, Getters and Setters break encapsulation.
>
> To be specific, there are classic articles such as
>
> http://www.javaworld.com/javaworld/j...5-toolbox.html
>
> or
>
> http://c2.com/cgi/wiki?AccessorsAreEvil
>
> .
> However, Java is not an fully object-oriented programming
> language and therefore, for Java programming one should
> adopt a Java style (not an OOP style). Getters and Setters
> are parts of the Java culture and of the Java Beans
> specification. Therefore, it is appropriate to use them in
> Java programming whenever deemed advantageous.
>

Wikipedia has two definitions for encapsulation; the c2.com article is
(legitimately IMO) questioning excessive use of accessors under the
terms of the second Wikipedia definition. Note the word "questioning":
that article has a bunch of nuanced arguments on both sides. It's in the
context of this second definition specifically that Patrick advanced his
objections.

It's not black and white, obviously. Even if we are restricting our
discussion to simple accessors (the getters and setters are simple
assignments or returns) then it's clearly still possible that the nature
of the particular object is such that no access can set the state to an
invalid one.

And as others have pointed out, it's entirely a situation-specific
matter as to whether a profusion of accessors is even a code-smell: you
want to use JPA entities and view-model classes with care, but their
very nature argues for exposing their guts.

But I do agree with some that in much teaching these ideas about
accessors do not get advanced. Students are therefore left with the
impression that _routine_ use of accessors is OK. What's worse is that
they don't even get the scoop on writing proper accessors (e.g.
mutability considerations), nor on object consistency or class
invariants. _This_ is the actual smell, not the considered use of accessors.

Getters and setters are not just "Java style". It's an issue for every
OOP language. Real-world objects describe both data (state) and
behaviour, and run the spectrum from [all state-no behaviour] to [no
state-all behaviour]. Practical considerations mean that not all
behaviour will have all of its required state in the same class: hence
accessors.

AHS
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
Having compilation error: no match for call to ‘(const __gnu_cxx::hash<long long int>) (const long long int&)’ veryhotsausage C++ 1 07-04-2008 05:41 PM
Is there any one who has been working with java for a long long time? Amanda Java 26 11-11-2006 12:43 AM
unsigned long long int to long double Daniel Rudy C Programming 5 09-20-2005 02:37 AM
Assigning unsigned long to unsigned long long George Marsaglia C Programming 1 07-08-2003 05:16 PM



Advertisments