![]() |
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_CLOS E); 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 |
Re: A question about some long java code that has getters/setters
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_CLOS E); > 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 |
Re: A question about some long java code that has getters/setters
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. |
Re: A question about some long java code that has getters/setters
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. |
Re: A question about some long java code that has getters/setters
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_CLOS E); > * * * * 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 |
Re: A question about some long java code that has getters/setters
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. |
Re: A question about some long java code that has getters/setters
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 |
Re: A question about some long java code that has getters/setters
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 |
Re: A question about some long java code that has getters/setters
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_CLOS E); >> 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 |
Re: A question about some long java code that has getters/setters
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. |
| All times are GMT. The time now is 08:36 PM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.