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 1 of 2  [1] 2  Next page →

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

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



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

public class TestMessagePanel extends JFrame {

    public TestMessagePanel() {
        MessagePanel messagePanel1 = new MessagePanel("Top Left");
        MessagePanel messagePanel2 = new MessagePanel("Top Right");
        MessagePanel messagePanel3 = new MessagePanel("Bottom Left");
        MessagePanel messagePanel4 = new MessagePanel("Bottom Right");
        messagePanel1.setBackground(Color.RED);
        messagePanel2.setBackground(Color.CYAN);
        messagePanel3.setBackground(Color.GREEN);
        messagePanel4.setBackground(Color.WHITE);
        messagePanel1.setCentered(true);

        setLayout(new GridLayout(2, 2));
        add(messagePanel1);
        add(messagePanel2);
        add(messagePanel3);
        add(messagePanel4);
    }

    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()
}

class MessagePanel extends JPanel {

    private String message = "Nope";
    private int xCoordinate = 20;
    private int yCoordinate = 20;
    private int interval = 10;
    private boolean centered;

    public MessagePanel() {
    }

    public MessagePanel(String message) {
        this.message = message;
    }

    public String getMessage() {
        return message;
    }

    public void setMessage(String message) {
        this.message = message;
        repaint();
    }

    public int getXCoordinate() {
        return xCoordinate;
    }

    public void setXCoordinate(int x) {
        this.xCoordinate = x;
        repaint();
    }

    public int getYCoordinate() {
        return yCoordinate;
    }

    public void setYCoordinate(int y) {
        this.xCoordinate = y;
        repaint();
    }

    public boolean isCentered() {
        return centered;
    }

    public void setCentered(boolean centered) {
        this.centered = centered;
        repaint();
    }

    public int getInterval() {
        return interval;
    }

    public void setInterval(int interval) {
        this.interval = interval;
        repaint();
    }

    protected void paintComponent(Graphics g) {
        super.paintComponent(g);

        if (centered) {
            FontMetrics fm = g.getFontMetrics();
            int stringWidth = fm.stringWidth(message);
            int stringAscent = fm.getAscent();
            xCoordinate = getWidth() / 2 - stringWidth / 2;
            yCoordinate = getWidth() / 2 - stringAscent / 2;
        }
        g.drawString(message, xCoordinate, yCoordinate);
    }

    public void MoveLeft() {
        xCoordinate -= interval;
        repaint();
    }

    public void MoveRight() {
        xCoordinate += interval;
        repaint();
    }

    public void moveUp() {
        yCoordinate -= interval;
        repaint();
    }

    public void moveDown() {
        yCoordinate += interval;
        repaint();
    }

    public Dimension getPreferredSize() {
        return new Dimension(200, 30);
    }
}


What I don't get is why the book defines stuff like getXCoordinate(),
getYCoordinate(), and getInterval() when it doesn't even use them in
this very long code example. I tried reading over the section in the
book, but the author gives no explanation on why he included a bunch
of unused getters/setters. On top of that, the code seems to work fine
when I comment out these methods.

Ideas?

Chad

[toc] | [next] | [standalone]

#6436

On 7/22/2011 7:12 PM, Chad wrote:
> The following code, which is taken from one of my school books,
> displays 4 different boxes inside a gui
>
>
>
> import java.awt.*;
> import javax.swing.*;
>
> public class TestMessagePanel extends JFrame {
>
>      public TestMessagePanel() {
>          MessagePanel messagePanel1 = new MessagePanel("Top Left");
>          MessagePanel messagePanel2 = new MessagePanel("Top Right");
>          MessagePanel messagePanel3 = new MessagePanel("Bottom Left");
>          MessagePanel messagePanel4 = new MessagePanel("Bottom Right");
>          messagePanel1.setBackground(Color.RED);
>          messagePanel2.setBackground(Color.CYAN);
>          messagePanel3.setBackground(Color.GREEN);
>          messagePanel4.setBackground(Color.WHITE);
>          messagePanel1.setCentered(true);
>
>          setLayout(new GridLayout(2, 2));
>          add(messagePanel1);
>          add(messagePanel2);
>          add(messagePanel3);
>          add(messagePanel4);
>      }
>
>      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()
> }
>
> class MessagePanel extends JPanel {
>
>      private String message = "Nope";
>      private int xCoordinate = 20;
>      private int yCoordinate = 20;
>      private int interval = 10;
>      private boolean centered;
>
>      public MessagePanel() {
>      }
>
>      public MessagePanel(String message) {
>          this.message = message;
>      }
>
>      public String getMessage() {
>          return message;
>      }
>
>      public void setMessage(String message) {
>          this.message = message;
>          repaint();
>      }
>
>      public int getXCoordinate() {
>          return xCoordinate;
>      }
>
>      public void setXCoordinate(int x) {
>          this.xCoordinate = x;
>          repaint();
>      }
>
>      public int getYCoordinate() {
>          return yCoordinate;
>      }
>
>      public void setYCoordinate(int y) {
>          this.xCoordinate = y;
>          repaint();
>      }
>
>      public boolean isCentered() {
>          return centered;
>      }
>
>      public void setCentered(boolean centered) {
>          this.centered = centered;
>          repaint();
>      }
>
>      public int getInterval() {
>          return interval;
>      }
>
>      public void setInterval(int interval) {
>          this.interval = interval;
>          repaint();
>      }
>
>      protected void paintComponent(Graphics g) {
>          super.paintComponent(g);
>
>          if (centered) {
>              FontMetrics fm = g.getFontMetrics();
>              int stringWidth = fm.stringWidth(message);
>              int stringAscent = fm.getAscent();
>              xCoordinate = getWidth() / 2 - stringWidth / 2;
>              yCoordinate = getWidth() / 2 - stringAscent / 2;
>          }
>          g.drawString(message, xCoordinate, yCoordinate);
>      }
>
>      public void MoveLeft() {
>          xCoordinate -= interval;
>          repaint();
>      }
>
>      public void MoveRight() {
>          xCoordinate += interval;
>          repaint();
>      }
>
>      public void moveUp() {
>          yCoordinate -= interval;
>          repaint();
>      }
>
>      public void moveDown() {
>          yCoordinate += interval;
>          repaint();
>      }
>
>      public Dimension getPreferredSize() {
>          return new Dimension(200, 30);
>      }
> }
>
>
> What I don't get is why the book defines stuff like getXCoordinate(),
> getYCoordinate(), and getInterval() when it doesn't even use them in
> this very long code example. I tried reading over the section in the
> book, but the author gives no explanation on why he included a bunch
> of unused getters/setters. On top of that, the code seems to work fine
> when I comment out these methods.
>
> Ideas?

There are two approaches to getters and setters:
* generate all except when you have a good reason not to
* generate only those you absolutely need

In this case I think the second approach is actually the best, but
I am a lazy bastard so I would like just ask my IDE to add all
the getters and setters anyway.

Arne

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

#6437

Chad <cdalten@gmail.com> wrote:
> What I don't get is why the book defines stuff like getXCoordinate(),
> getYCoordinate(), and getInterval() when it doesn't even use them in
> this very long code example. ...

I can't speak for the authors, but I might have included these into
a book for a few reasons:  get the students more used to correctly
camelCasing method names, and because they are standard methods 
typically found in widget libraries.

>     public Dimension getPreferredSize() {
>         return new Dimension(200, 30);
>     }

Some others of these methods like getPreferredSize() are called by
the framework, but I wouldn't expect that for the methods you speci-
fically asked about.

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

#6439

On 7/22/2011 4:12 PM, Chad wrote:
> What I don't get is why the book defines stuff like getXCoordinate(),
> getYCoordinate(), and getInterval() when it doesn't even use them


Dead code is often a fact of life.  OTOH, some reasonable reasons might be:

Those methods are called by a unit test harness, which is not shown.

Those methods are used elsewhere in a different code base, and this 
class is a general purpose class developed by the author as part of his 
text book.

You might look ahead and see if this class appears again in the book, 
maybe with the "unused" methods invoked there.

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

#6458

Chad wrote:
> 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() {
>         MessagePanel messagePanel1 = new MessagePanel("Top Left");
>         MessagePanel messagePanel2 = new MessagePanel("Top Right");
>         MessagePanel messagePanel3 = new MessagePanel("Bottom Left");
>         MessagePanel messagePanel4 = new MessagePanel("Bottom Right");
>         messagePanel1.setBackground(Color.RED);
>         messagePanel2.setBackground(Color.CYAN);
>         messagePanel3.setBackground(Color.GREEN);
>         messagePanel4.setBackground(Color.WHITE);
>         messagePanel1.setCentered(true);
>
>         setLayout(new GridLayout(2, 2));
>         add(messagePanel1);
>         add(messagePanel2);
>         add(messagePanel3);
>         add(messagePanel4);
>     }
>
>     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()
>
> }
>
> class MessagePanel extends JPanel {
>
>     private String message = "Nope";
>     private int xCoordinate = 20;
>     private int yCoordinate = 20;
>     private int interval = 10;
>     private boolean centered;
>
>     public MessagePanel() {
>     }
>
>     public MessagePanel(String message) {
>         this.message = message;
>     }
>
>     public String getMessage() {
>         return message;
>     }
>
>     public void setMessage(String message) {
>         this.message = message;
>         repaint();
>     }
>
>     public int getXCoordinate() {
>         return xCoordinate;
>     }
>
>     public void setXCoordinate(int x) {
>         this.xCoordinate = x;
>         repaint();
>     }
>
>     public int getYCoordinate() {
>         return yCoordinate;
>     }
>
>     public void setYCoordinate(int y) {
>         this.xCoordinate = y;
>         repaint();
>     }
>
>     public boolean isCentered() {
>         return centered;
>     }
>
>     public void setCentered(boolean centered) {
>         this.centered = centered;
>         repaint();
>     }
>
>     public int getInterval() {
>         return interval;
>     }
>
>     public void setInterval(int interval) {
>         this.interval = interval;
>         repaint();
>     }
>
>     protected void paintComponent(Graphics g) {
>         super.paintComponent(g);
>
>         if (centered) {
>             FontMetrics fm = g.getFontMetrics();
>             int stringWidth = fm.stringWidth(message);
>             int stringAscent = fm.getAscent();
>             xCoordinate = getWidth() / 2 - stringWidth / 2;
>             yCoordinate = getWidth() / 2 - stringAscent / 2;
>         }
>         g.drawString(message, xCoordinate, yCoordinate);
>     }
>
>     public void MoveLeft() {
>         xCoordinate -= interval;
>         repaint();
>     }
>
>     public void MoveRight() {
>         xCoordinate += interval;
>         repaint();
>     }
>
>     public void moveUp() {
>         yCoordinate -= interval;
>         repaint();
>     }
>
>     public void moveDown() {
>         yCoordinate += interval;
>         repaint();
>     }
>
>     public Dimension getPreferredSize() {
>         return new Dimension(200, 30);
>     }
>
> }
>
> What I don't get is why the book defines stuff like getXCoordinate(),
> getYCoordinate(), and getInterval() when it doesn't even use them in
> this very long code example. I tried reading over the section in the
> book, but the author gives no explanation on why he included a bunch
> of unused getters/setters. On top of that, the code seems to work fine
> when I comment out these methods.
>
> Ideas?

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.

It is standard practice to create accessors and mutators for class
attributes.  There's nothing wrong with that.  The class is written as
any good API writer (a.k.a. "programmer") should in that one respect.
While you should not build features into a class on a remote chance of
their use, if you have properties then you should provide the get/set
methods for them quite nearly always.

But you should never, never, never do GUI magic off the EDT!

It's also bad practice to use import-on-demand (import '*') rather
than single-type imports.

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

--
Lew

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

#6471

In article <1672e2f1-a963-4fcf-b651-41b69432c9d7@p29g2000pre.googlegroups.com>,
lewbloch  <lewbloch@gmail.com> wrote:
> Chad wrote:
> > 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.*;

[ snip ]

> It's also bad practice to use import-on-demand (import '*') rather
> than single-type imports.

In code meant for compiling and execution, agreed.  In code meant
for display in dead-tree documentation, though ....  I think there's
a case to be made for the "import ...*" form, so that code examples
aren't so full of uninteresting lines, accompanied by an explanation
somewhere that in "real" code one would import only those classes
needed.

(By the way -- are you the person who used to post using the address
noone@lewscanon.com, or a different Lew?)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

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

#6472

blm...@myrealbox.com wrote:
> (By the way -- are you the person who used to post using the address
> no...@lewscanon.com, or a different Lew?)
>

Same Lew.

I recently relocated and my regular computer is in storage until I get
a more permanent address.  This somewhat limits my access to my Gmail
account and web-based Usenet until I get my regular equipment back.

--
Lew

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

#6483

On 7/23/2011 1:41 PM, blmblm@myrealbox.com wrote:
> In article<1672e2f1-a963-4fcf-b651-41b69432c9d7@p29g2000pre.googlegroups.com>,
> lewbloch<lewbloch@gmail.com>  wrote:
>> Chad wrote:
>>> 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.*;
>
> [ snip ]
>
>> It's also bad practice to use import-on-demand (import '*') rather
>> than single-type imports.
>
> In code meant for compiling and execution, agreed.  In code meant
> for display in dead-tree documentation, though ....  I think there's
> a case to be made for the "import ...*" form, so that code examples
> aren't so full of uninteresting lines, accompanied by an explanation
> somewhere that in "real" code one would import only those classes
> needed.

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.

Arne

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

#6498

In article <4e2b4456$0$306$14726298@news.sunsite.dk>, Arne Vajhøj 
says...
> 
> On 7/23/2011 1:41 PM, blmblm@myrealbox.com wrote:

> >> It's also bad practice to use import-on-demand (import '*') rather
> >> than single-type imports.
> >
> > In code meant for compiling and execution, agreed.  In code meant
> > for display in dead-tree documentation, though ....  
> 
> 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, 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 :)



-- 
Steve Sobol - Programming/WebDev/IT Support
sjsobol@JustThe.net

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

#6550

In article <MPG.28955e1a28096dbd9897c8@news.justthe.net>,
Steve Sobol  <sjsobol@JustThe.net> wrote:
> In article <4e2b4456$0$306$14726298@news.sunsite.dk>, Arne Vajhøj 
> says...
> > 
> > On 7/23/2011 1:41 PM, blmblm@myrealbox.com wrote:
> 
> > >> It's also bad practice to use import-on-demand (import '*') rather
> > >> than single-type imports.
> > >
> > > In code meant for compiling and execution, agreed.  In code meant
> > > for display in dead-tree documentation, though ....  
> > 
> > Having specific imports makes it easier to see where the classes
> > come from.

Well, there is that.  Good point.

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

I'm not sure I agree, but maybe you can convince me ....  Why?

> I agree. And I can't speak for other IDE's, 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 :)

True, and one of the reasons I find Eclipse a useful tool despite
my strong preference for editing any kind of text with, um, a
different tool.  :-)?

However, my point was not that it's difficult to generate a list
of specific imports -- I know better -- but that including one in
printed material clutters up the page with details unlikely to be
important (though obviously not everyone agrees with me on that).

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

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

#6582

On Jul 23, 11:39 pm, Steve Sobol <sjso...@JustThe.net> wrote:
> In article <4e2b4456$0$306$14726...@news.sunsite.dk>, Arne Vajhøj
> says...
>
>
>
> > On 7/23/2011 1:41 PM, blm...@myrealbox.com wrote:
> > >> It's also bad practice to use import-on-demand (import '*') rather
> > >> than single-type imports.
>
> > > In code meant for compiling and execution, agreed.  In code meant
> > > for display in dead-tree documentation, though ....  
>
> > 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.

--
Lew

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

#6487

On 7/23/2011 12:02 PM, lewbloch wrote:
> Chad wrote:
>> 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() {
>>          MessagePanel messagePanel1 = new MessagePanel("Top Left");
>>          MessagePanel messagePanel2 = new MessagePanel("Top Right");
>>          MessagePanel messagePanel3 = new MessagePanel("Bottom Left");
>>          MessagePanel messagePanel4 = new MessagePanel("Bottom Right");
>>          messagePanel1.setBackground(Color.RED);
>>          messagePanel2.setBackground(Color.CYAN);
>>          messagePanel3.setBackground(Color.GREEN);
>>          messagePanel4.setBackground(Color.WHITE);
>>          messagePanel1.setCentered(true);
>>
>>          setLayout(new GridLayout(2, 2));
>>          add(messagePanel1);
>>          add(messagePanel2);
>>          add(messagePanel3);
>>          add(messagePanel4);
>>      }
>>
>>      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()
>>
>> }
>>
>> class MessagePanel extends JPanel {
>>
>>      private String message = "Nope";
>>      private int xCoordinate = 20;
>>      private int yCoordinate = 20;
>>      private int interval = 10;
>>      private boolean centered;
>>
>>      public MessagePanel() {
>>      }
>>
>>      public MessagePanel(String message) {
>>          this.message = message;
>>      }
>>
>>      public String getMessage() {
>>          return message;
>>      }
>>
>>      public void setMessage(String message) {
>>          this.message = message;
>>          repaint();
>>      }
>>
>>      public int getXCoordinate() {
>>          return xCoordinate;
>>      }
>>
>>      public void setXCoordinate(int x) {
>>          this.xCoordinate = x;
>>          repaint();
>>      }
>>
>>      public int getYCoordinate() {
>>          return yCoordinate;
>>      }
>>
>>      public void setYCoordinate(int y) {
>>          this.xCoordinate = y;
>>          repaint();
>>      }
>>
>>      public boolean isCentered() {
>>          return centered;
>>      }
>>
>>      public void setCentered(boolean centered) {
>>          this.centered = centered;
>>          repaint();
>>      }
>>
>>      public int getInterval() {
>>          return interval;
>>      }
>>
>>      public void setInterval(int interval) {
>>          this.interval = interval;
>>          repaint();
>>      }
>>
>>      protected void paintComponent(Graphics g) {
>>          super.paintComponent(g);
>>
>>          if (centered) {
>>              FontMetrics fm = g.getFontMetrics();
>>              int stringWidth = fm.stringWidth(message);
>>              int stringAscent = fm.getAscent();
>>              xCoordinate = getWidth() / 2 - stringWidth / 2;
>>              yCoordinate = getWidth() / 2 - stringAscent / 2;
>>          }
>>          g.drawString(message, xCoordinate, yCoordinate);
>>      }
>>
>>      public void MoveLeft() {
>>          xCoordinate -= interval;
>>          repaint();
>>      }
>>
>>      public void MoveRight() {
>>          xCoordinate += interval;
>>          repaint();
>>      }
>>
>>      public void moveUp() {
>>          yCoordinate -= interval;
>>          repaint();
>>      }
>>
>>      public void moveDown() {
>>          yCoordinate += interval;
>>          repaint();
>>      }
>>
>>      public Dimension getPreferredSize() {
>>          return new Dimension(200, 30);
>>      }
>>
>> }
>>
>> What I don't get is why the book defines stuff like getXCoordinate(),
>> getYCoordinate(), and getInterval() when it doesn't even use them in
>> this very long code example. I tried reading over the section in the
>> book, but the author gives no explanation on why he included a bunch
>> of unused getters/setters. On top of that, the code seems to work fine
>> when I comment out these methods.
>>
>> Ideas?
>
> 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.
>
> It is standard practice to create accessors and mutators for class
> attributes.  There's nothing wrong with that.  The class is written as
> any good API writer (a.k.a. "programmer") should in that one respect.
> While you should not build features into a class on a remote chance of
> their use, if you have properties then you should provide the get/set
> methods for them quite nearly always.
>
> 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.

Arne

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

#6581

Arne Vajhøj wrote:
> lewbloch wrote:
>> Chad wrote:
>>> 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.

--
Lew

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

#6553

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

Patrick

------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation.  (C++, Java, Common Lisp, Jini, middleware, SOA)

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

#6554

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.

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

#6555

On Jul 25, 1:27 pm, Patrick May <patr...@softwarematters.org> wrote:
> lewbloch <lewbl...@gmail.com> 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

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

#6557

On 7/25/2011 3:56 PM, lewbloch wrote:
> On Jul 25, 1:27 pm, Patrick May<patr...@softwarematters.org>  wrote:
>> lewbloch<lewbl...@gmail.com>  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. :-(

Patricia

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

#6559

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<patr...@softwarematters.org> wrote:
>>> lewbloch<lewbl...@gmail.com> 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
esosman@ieee-dot-org.invalid

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

#6556

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.

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

#6560

On 26 Jul 2011 00:42:20 GMT, ram@zedat.fu-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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web