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

[lewbloch]

The following code, which is taken from one of my school books,
displays 4 different boxes inside a gui [sic]

import java.awt.*;
import javax.swing.*;

public class TestMessagePanel extends JFrame {

     public TestMessagePanel() {
...
     }

     public static void main(String[] args) {
         TestMessagePanel frame = new TestMessagePanel();
         frame.setSize(300, 200);
         frame.setTitle("TestMessagePanel");
         frame.setLocationRelativeTo(null);
         frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
         frame.setVisible(true);

     }//end main()

}
...

The problem with this code is that it teaches the bad and bug-prone
practice of creating GUI elements on the main thread instead of the
EDT.  Don't use this book.  The author apparently didn't know what he
was doing.
...
But you should never, never, never do GUI magic off the EDT!

Maybe the book is just not new.

It was common practice to initiate the Swing form from the
main thread for some years until people got aware of the
potential issue.

That may be the excuse, but it doesn't improve the usefulness of the
book. He should still get a book that shows the correct idioms.

And it isn't a potential issue, it's an actual issue.

 

[lewbloch]

Having specific imports makes it easier to see where the classes
come from.

I would tend to say that is even more important for dead tree docs
than for code.

I agree. And I can't speak for other IDE's [sic], but in Eclipse, updating
your list of specific imports can be done by hitting Ctrl-Shift-O.
("Organize Imports")

Takes a fraction of a second

I believe it's Ctrl-Shift-I for the exact same feature in NetBeans.
No doubt IntelliJ and others have the same feature.

 

[lewbloch]

  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".

 

[lewbloch]

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.

 

[Gene Wirchenko]

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

 

[Stefan Ram]

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).

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.

 

[Gene Wirchenko]

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).


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

 

[Stefan Ram]

(insert »according to their contract«, here)

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.

 

[Stefan Ram]

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.

A reasonable implementation might be:

public void SetCopies( final int number )
{ this.printerDelegate.setCopies( number ); }

, i.e., one which does not modify an instance variable, or

public void SetCopies( final int number )
{ this.getPrinterDelegate().setCopies( number ); }

, i.e., one which does not use any instance variable.

 

[Stefan Ram]

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.

I now try to look it up in the »Wikipedia.« The first relevant content
I find with my search approach is:

»Unlike the "getter" and "setter" methods of other
languages like C++ or Java, accessor methods in Ruby are
created with a single line of code via metaprogramming.«

http://en.wikipedia.org/wiki/Ruby_(programming_language)

This seems to imply the meaning »1.«.

The next hit:

»Integer extend [
asClosure [
| value |
value := self.
^{ [ :x | value := x ]. [ value ] }
]
]

blocks := 10 asClosure.
setter := blocks first.
getter := blocks second.
getter value "=> 10"
setter value: 21 "=> 21"
getter value "=> 21"«

http://en.wikipedia.org/wiki/GNU_Smalltalk

This also seems to imply an access to the internal
variable »value« of the closure. Disclaimer: I did
not learn Smalltalk yet.

Found Last, but not appreciated least, the main article:

»The mutator method, sometimes called a "setter", is
most often used in object-oriented programming, in
keeping with the principle of encapsulation. According
to this principle, member variables of a class are made
private to hide and protect them from other code, and
can only be modified by a public member function (the
mutator method), which takes the desired new value as a
parameter, optionally validates it, and modifies the
private member variable.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Often a "setter" is accompanied by a "getter" (also
known as an accessor), which returns the value of the
private member variable.«
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
http://en.wikipedia.org/wiki/Mutator_method

Reads like more close to »1.« to me.

(The foregoing quotations from the »Wikipedia« that I have
provided in this Usenet post were not written into the
»Wikipedia« by me. I never edited any of the »Wikipedia«
articles quoted above, I just underlined two lines in this
Usenet post.)

 

[lewbloch]

  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).


  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.

 

[lewbloch]

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

 

[Jukka Lahtinen]

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

[/QUOTE]

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.

 

[Stefan Ram]

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.

For a property of an object, you could also use the term
»property« (no surprise intended here). You have made the point
yourself, that a method to modify a property should be accompanied
by a method to read a property, but where this is not the case,
we could use »read-only property« or »write-only property«.

This also would have the advantage that it would use the terms
in the way already established in the field.

 

[lewbloch]

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.