Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #6434 > unrolled thread

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

Back to article view | Back to comp.lang.java.programmer

Contents

  A question about some long java code that has getters/setters Chad <cdalten@gmail.com> - 2011-07-22 16:12 -0700
    Re: A question about some long java code that has getters/setters Arne Vajhøj <arne@vajhoej.dk> - 2011-07-22 19:28 -0400
    Re: A question about some long java code that has getters/setters Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-22 23:31 +0000
    Re: A question about some long java code that has getters/setters markspace <-@.> - 2011-07-22 16:51 -0700
    Re: A question about some long java code that has getters/setters lewbloch <lewbloch@gmail.com> - 2011-07-23 09:02 -0700
      Re: A question about some long java code that has getters/setters blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-23 17:41 +0000
        Re: A question about some long java code that has getters/setters lewbloch <lewbloch@gmail.com> - 2011-07-23 11:42 -0700
        Re: A question about some long java code that has getters/setters Arne Vajhøj <arne@vajhoej.dk> - 2011-07-23 17:59 -0400
          Re: A question about some long java code that has getters/setters Steve Sobol <sjsobol@JustThe.net> - 2011-07-23 23:39 -0700
            Re: A question about some long java code that has getters/setters blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-25 19:44 +0000
            Re: A question about some long java code that has getters/setters lewbloch <lewbloch@gmail.com> - 2011-07-26 09:03 -0700
      Re: A question about some long java code that has getters/setters Arne Vajhøj <arne@vajhoej.dk> - 2011-07-23 19:26 -0400
        Re: A question about some long java code that has getters/setters lewbloch <lewbloch@gmail.com> - 2011-07-26 09:00 -0700
      Re: A question about some long java code that has getters/setters Patrick May <patrick@softwarematters.org> - 2011-07-25 16:27 -0400
        Re: A question about some long java code that has getters/setters markspace <-@.> - 2011-07-25 15:14 -0700
        Re: A question about some long java code that has getters/setters lewbloch <lewbloch@gmail.com> - 2011-07-25 15:56 -0700
          Re: A question about some long java code that has getters/setters Patricia Shanahan <pats@acm.org> - 2011-07-25 17:00 -0700
            Re: A question about some long java code that has getters/setters Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-25 21:17 -0400
        Re: A question about some long java code that has getters/setters markspace <-@.> - 2011-07-25 16:50 -0700
          Re: A question about some long java code that has getters/setters Gene Wirchenko <genew@ocis.net> - 2011-07-25 18:30 -0700
            Re: A question about some long java code that has getters/setters Patricia Shanahan <pats@acm.org> - 2011-07-25 18:41 -0700
            Re: A question about some long java code that has getters/setters lewbloch <lewbloch@gmail.com> - 2011-07-26 09:05 -0700
            Re: A question about some long java code that has getters/setters Gene Wirchenko <genew@ocis.net> - 2011-07-26 10:48 -0700
              Re: A question about some long java code that has getters/setters Gene Wirchenko <genew@ocis.net> - 2011-07-26 11:56 -0700
                Re: A question about some long java code that has getters/setters Patricia Shanahan <pats@acm.org> - 2011-07-26 13:34 -0700
                  Re: A question about some long java code that has getters/setters lewbloch <lewbloch@gmail.com> - 2011-07-26 14:21 -0700
              Re: A question about some long java code that has getters/setters lewbloch <lewbloch@gmail.com> - 2011-07-26 14:20 -0700
          Re: A question about some long java code that has getters/setters Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-25 21:35 -0400
          Re: A question about some long java code that has getters/setters Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-26 06:59 -0300
      Re: A question about some long java code that has getters/setters Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-07-26 12:19 +0300
        Re: A question about some long java code that has getters/setters lewbloch <lewbloch@gmail.com> - 2011-07-26 09:08 -0700
          Re: A question about some long java code that has getters/setters Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-07-27 15:56 +0300
            Re: A question about some long java code that has getters/setters lewbloch <lewbloch@gmail.com> - 2011-07-27 14:14 -0700

Page 2 of 2 — ← Prev page 1 [2]

#6562

On 7/25/2011 6:30 PM, Gene Wirchenko wrote:
...
>       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();

In this sort of situation I would always have the corresponding getters.
In general, if an object needs to set a knob it should be able to see
the current setting, for a couple of purposes:

1. Logging the settings it controls.

2. Being able to temporarily change settings and put back the old value.

Patricia

[toc] | [prev] | [next] | [standalone]

#6583

On Jul 26, 2:15 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Gene Wirchenko <ge...@ocis.net> 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«.)

If one were following the Java naming conventions, it would be a
method whose name begins with "set".

--
Lew

[toc] | [prev] | [next] | [standalone]

#6588

On 26 Jul 2011 09:15:51 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:

>Gene Wirchenko <genew@ocis.net> 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«?

     In my example, yes.  In general, no.

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

     Are you going by whether the setter uncritically sets the value
or whether it checks the value?  To me, the former is bad, but the
latter is fine.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#6591

On 26 Jul 2011 18:20:41 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:

>Gene Wirchenko <genew@ocis.net> writes:
>>>>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«?
>>In my example, yes.  In general, no.
>
>  There is nothing wrong with one-argument methods whose
>  name begins with »Set« (except that common Java naming
>  style is to use lower-case method names).
>
>>>(To apply my own definition, I would need to see the
>>>documentation of a method, to judge whether it is a »setter«.)
>>Are you going by whether the setter uncritically sets the value
>>or whether it checks the value?
>
>  According to
>
>http://c2.com/cgi/wiki?AccessorsAreEvil
>
>      »accessors are methods that let you read and write the
>      value of an instance variable of an object«.
>
>  My personal definition is similar:
>
>      »An accessor is any method whose contract contains a
>      reference to an instance variable.«

     Then, the answer is no.  However, the contract for such a method
of mine would have reference to the concept that the instance variable
embodies.  I might write the contract for .SetCopies() as:

     .SetCopies() takes one parameter, an integer which is the number
of copies of the file to be printed that will be made when .Print() is
called (assuming sufficient valid printing parameters have been set).
The number of copies must be non-negative.

     If I am reading you correctly, for the above, the answer is no,
but if I change the contract to refer to the instance variable, say
.NumCopies, then it would be a setter.  This distinction strikes me as
rather less than useful.  "So, is it a setter?"  "I can not tell.  I
have not read the contract."

>  Since I do not know whether your methods set the value of an
>  instance variable, I do not know, whether they are »setters«
>  in the sense of my definition. I would need to be able to
>  read their contract (documentation) to learn about this.

     Read my example contract above.  It does not mention an instance
variable, but any reasonable implementation that I am likely to do
would use one.

>  When their contract (documentation) does not contain such
>  references, encapsulation is not broken.

     They set something.  Whether it is an instance variable or not is
irrelevant to their use.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#6594

On 7/26/2011 12:15 PM, Stefan Ram wrote:
> Gene Wirchenko<genew@ocis.net>  writes:
>>> Since I do not know whether your methods
>
>    (insert »according to their contract«, here)
>
>>>                                          set the value of an
>>> instance variable, I do not know, whether they are »setters«
>>> in the sense of my definition. I would need to be able to
>>> read their contract (documentation) to learn about this.
>> Read my example contract above.  It does not mention an instance
>> variable, but any reasonable implementation that I am likely to do
>> would use one.
>
>    Ok, then - to me - it is not a »setter«.
>
>> They set something.  Whether it is an instance variable or not is
>> irrelevant to their use.
>
>    That is even another reason not to make references to instance
>    variables in the contract of a method.
>
>    A »Setter« to me is a method with a contract like:
>
>        »... sets the private field "alpha" to the argument value.«
>
>    Your method does not set a »field« but a »property« of the object.
>    Its contract does not allow a party to deduce with
>    certainity something about the private fields of the object.
>    Therefore, it does not break encapsulation.
>

We have two possible definitions of "setter", with corresponding
definitions for "getter".

1. A method whose contract specifies setting an instance variable.

2. A method whose contract specifies setting a logical property of the
object.

To me, it seems wasteful to use an nice, short, simple term for
something that should *never* exist, when it could equally well be used
for something that is actually useful, so I prefer the second definition.

Patricia

[toc] | [prev] | [next] | [standalone]

#6596

On Jul 26, 1:34 pm, Patricia Shanahan <p...@acm.org> wrote:
> On 7/26/2011 12:15 PM, Stefan Ram wrote:
>
>
>
>
>
>
>
>
>
> > Gene Wirchenko<ge...@ocis.net>  writes:
> >>> Since I do not know whether your methods
>
> >    (insert according to their contract , here)
>
> >>>                                          set the value of an
> >>> instance variable, I do not know, whether they are setters
> >>> in the sense of my definition. I would need to be able to
> >>> read their contract (documentation) to learn about this.
> >> Read my example contract above.  It does not mention an instance
> >> variable, but any reasonable implementation that I am likely to do
> >> would use one.
>
> >    Ok, then - to me - it is not a setter .
>
> >> They set something.  Whether it is an instance variable or not is
> >> irrelevant to their use.
>
> >    That is even another reason not to make references to instance
> >    variables in the contract of a method.
>
> >    A Setter to me is a method with a contract like:
>
> >         ... sets the private field "alpha" to the argument value.
>
> >    Your method does not set a field but a property of the object.
> >    Its contract does not allow a party to deduce with
> >    certainity something about the private fields of the object.
> >    Therefore, it does not break encapsulation.
>
> We have two possible definitions of "setter", with corresponding
> definitions for "getter".
>
> 1. A method whose contract specifies setting an instance variable.
>
> 2. A method whose contract specifies setting a logical property of the
> object.
>
> To me, it seems wasteful to use an nice, short, simple term for
> something that should *never* exist, when it could equally well be used
> for something that is actually useful, so I prefer the second definition.

+1

--
Lew

[toc] | [prev] | [next] | [standalone]

#6599

On Jul 26, 11:20 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Gene Wirchenko <ge...@ocis.net> writes:
> >>>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 ?
> >In my example, yes.  In general, no.
>
>   There is nothing wrong with one-argument methods whose
>   name begins with Set (except that common Java naming
>   style is to use lower-case method names).
>
> >>(To apply my own definition, I would need to see the
> >>documentation of a method, to judge whether it is a setter .)
> >Are you going by whether the setter uncritically sets the value
> >or whether it checks the value?
>
>   According to
>
> http://c2.com/cgi/wiki?AccessorsAreEvil
>
>       accessors are methods that let you read and write the
>       value of an instance variable of an object .
>
>   My personal definition is similar:
>
>       An accessor is any method whose contract contains a
>       reference to an instance variable.
>
>   Since I do not know whether your methods set the value of an
>   instance variable, I do not know, whether they are setters
>   in the sense of my definition. I would need to be able to
>   read their contract (documentation) to learn about this.
>
>   When their contract (documentation) does not contain such
>   references, encapsulation is not broken.

Strictly speaking an accessor need not reference an instance variable
of the class that owns the accessor.  It only needs to give the
appearance of doing so.  Gene Wirchenko makes the excellent point that
accessors can and often should include sanity logic, i.e., logic to
preserve invariants.

--
Lew

[toc] | [prev] | [next] | [standalone]

#6561

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
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#6572

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/jw-09-2003/jw-0905-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

[toc] | [prev] | [next] | [standalone]

#6571

lewbloch <lewbloch@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#6585

On Jul 26, 2:19 am, Jukka Lahtinen <jtfjd...@hotmail.com.invalid>
wrote:
> lewbloch <lewbl...@gmail.com> 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?

Yes, as long as I also chose the books the teacher specified.

I had Calculus III with a book that mixed up the "u", "v" and "w"
variables in the examples.  I spent many a sleepless night puzzling
whether the book was wrong or I was.  At least three-quarters of the
time it was the book.

If you are committed to learning and the book is bad, you get a good
book and learn it independently of whatever the professor mandates.
If you're only committed to doing the minimum and winding up knowing
nothing, you use the bad book.

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

And to get a good book.

--
Lew

[toc] | [prev] | [next] | [standalone]

#6610

lewbloch <lewbloch@gmail.com> writes:
> On Jul 26, 2:19 am, Jukka Lahtinen <jtfjd...@hotmail.com.invalid>

>> lewbloch <lewbl...@gmail.com> 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.

>> TOP told us it's a school book. When at school, were you allowed to
>> choose the books yourself?

> Yes, as long as I also chose the books the teacher specified.
..
> If you are committed to learning and the book is bad, you get a good
> book and learn it independently of whatever the professor mandates.

Of course, a dedicated student may read good books in addition to what
the school requires. But the point is, they often can't just ditch the
book required for the studies, no matter how bad it is.
They often need to do exercises from the given book, and the book, no
matter how bad it is, probably makes it easier to follow the lectures
and summarize what has already been taught.

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#6620

On Jul 27, 5:56 am, Jukka Lahtinen <jtfjd...@hotmail.com.invalid>
wrote:
> lewbloch <lewbl...@gmail.com> writes:
> > On Jul 26, 2:19 am, Jukka Lahtinen <jtfjd...@hotmail.com.invalid>
> >> lewbloch <lewbl...@gmail.com> 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.
> >> TOP told us it's a school book. When at school, were you allowed to
> >> choose the books yourself?
> > Yes, as long as I also chose the books the teacher specified.
> ..
> > If you are committed to learning and the book is bad, you get a good
> > book and learn it independently of whatever the professor mandates.
>
> Of course, a dedicated student may read good books in addition to what
> the school requires. But the point is, they often can't just ditch the
> book required for the studies, no matter how bad it is.
> They often need to do exercises from the given book, and the book, no
> matter how bad it is, probably makes it easier to follow the lectures
> and summarize what has already been taught.

I avoided suggesting dropping the bad book for exactly that reason.  I
see you agree with me that the good books should be used in addition
to what the school requires.

The question is whether you want to learn the material or merely pass
the course.  It is common to get misinformation even at university,
and incumbent on the student to make sure they aren't fooled.

--
Lew

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web