Java class with set and get method

G

Gleys

I have following question:

I must create a class with the properties: color, width, length,
weight;
height.
So, I create a new class BOX and define the properties:

public class Box
{
public String color;
public int width;
public int length;
public int height;
public int weight;
}

And now I must create the get method and the set method. But I don't
know
for what these methods are and how I create it. And at the end I must
create
a clear() method which will initialize the properties to 0 or empty.

My solution:

public class Box
{
public String color;
public int width;
public int length;
public int height;
public int weight;
public Box ()
{
this.color = "BLUE";
this.width = 5;
this.length = 2;
this.height = 3;
this.weight = 4;
}

public static void main (String[] args)
{
Box Box1 = new Box ();
System.out.println (Box1.color);
System.out.println (Box1.width);
System.out.println (Box1.length);
System.out.println (Box1.height);
System.out.println (Box1.weight);

}

public void Clear ()
{
Clear ();
}
}

Is the get and the set method correct or how I must do it? And for
what are this methods exactly?
 
K

kaeli

And now I must create the get method and the set method. But I don't
know
for what these methods are and how I create it.

Getters and setters are needed for bean introspectors to work right, for JSP
beans to work right, and just because people are used to them. :)
There's other reasons, too. Hiding variables, being able to do error checking
on variables (make sure values are in a range, etc) and more.
{
public String color;

This defeats one of the reasons for getters and setters - to hide instance
variables to outside things.

private (or protected) String color;

For a getter, do
public String getColor()
{
return this.color;
}

This is important - the case matters ('get' + variable with first letter
capped) and the return type matches the type of the variable.

For a setter:
public void setColor(String color)
{
this.color = color;
}

--
--
~kaeli~
To steal ideas from one person is plagiarism; to steal from
many is research.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace
 
E

Eric Sosman

kaeli said:
[...]
For a getter, do
public String getColor()
{
return this.color;
}

This is important - the case matters ('get' + variable with first letter
capped) and the return type matches the type of the variable.

Point of information: Is it required that there
actually be a variable named `color' corresponding to
methods getColor() and setColor()? Would anything
break if

private String colour; // English

public string getColor() { // Murkin
return colour;
}

Reaching just a little further, need there be a
backing variable at all? What about

private double width;
private double height;

public double getArea() {
return width * height;
}
 
P

Paul Lutus

Eric said:
kaeli said:
[...]
For a getter, do
public String getColor()
{
return this.color;
}

This is important - the case matters ('get' + variable with first letter
capped) and the return type matches the type of the variable.

Point of information: Is it required that there
actually be a variable named `color' corresponding to
methods getColor() and setColor()?

If that were true, there would be no point going on about encapsulation. The
entire idea of encapsulation is that the interface is separate from the
implementation.

You can implement your setters and getters any way you see fit, using any
names you feel are appropriate.
 
E

Eric Sosman

Paul said:
Eric Sosman wrote:

kaeli said:
[...]
For a getter, do
public String getColor()
{
return this.color;
}

This is important - the case matters ('get' + variable with first letter
capped) and the return type matches the type of the variable.

Point of information: Is it required that there
actually be a variable named `color' corresponding to
methods getColor() and setColor()?


If that were true, there would be no point going on about encapsulation. The
entire idea of encapsulation is that the interface is separate from the
implementation.

You can implement your setters and getters any way you see fit, using any
names you feel are appropriate.

Good: Some sanity survives. It's clear that this
is true from a "purely Java" viewpoint, but I was worried
that some strange J2EE/bean/tools convention might require
otherwise. Thanks for the reassurance.
 
M

Mike Schilling

Eric Sosman said:
Good: Some sanity survives. It's clear that this
is true from a "purely Java" viewpoint, but I was worried
that some strange J2EE/bean/tools convention might require
otherwise. Thanks for the reassurance.

You're a Sun employee, and you have no better place to ask these questions
than Usenet?
 
J

Jacob

LÄÊ»ie Techie said:
BTW, wouldn't Color be a more appropriate type for color than String?

This depends on context. The java.awt.Color class model a color
concept suited for use in a GUI environment, a "renderable" color.

As used in the original post of this thread, the color is more of a
general feature, a property, of the class instances. Introducing AWT
would be a bug really, though tempting as you get a lot of functionality
for free. In a proper MVC oriented design, "M"-code should not use
GUI concepts, so java.awt.Color is really not available.

Sun could have resolved this problem easily by having the Color class
in java.util rather than in java.awt; Possibly with a limited set of
features.

Another class that share this problem is javax.swing.table.TableModel.
A table model is a powerful concept, and should be available for use
in the modelling part of a program. Being located within javax.swing
(I'd claim) that's not possible.
 
J

Jim Cochrane

You're a Sun employee, and you have no better place to ask these questions
than Usenet?

Sun has had a lot of layoffs recently. The Java programmers remaining
are probably too busy with all the extra work to answer his questons. :)
 
E

Eric Sosman

Mike said:
You're a Sun employee, and you have no better place to ask these questions
than Usenet?

I'm a Sun employee, and a firm believer in an
observation made by (or attributed to) a former
Sun employee by the name of Bill Joy: "Remember,
most of the smart people don't work for you."
 
H

hilz

Good: Some sanity survives. It's clear that this
is true from a "purely Java" viewpoint, but I was worried
that some strange J2EE/bean/tools convention might require
otherwise. Thanks for the reassurance.


Well... i just started reading "Hibernate in Action" and learning the
Hibernate framework.
I am not sure if this is true, but it seems like hibernate has this kind of
restriction.
for example, in the case of this example,

private double width;
private double height;

public double getArea() {
return width * height;
}

in order to make the width and height persistent in the database, you will
HAVE to provide the getter and setter (they can have private access thought,
but they have to exist).

So to answer your question, i think yes, they might be needed by some
framework.
but anyways, since i am still in chapter 3 of the book, i might be wrong! :)

thanks
hilz
 
P

Paul Lutus

hilz said:
Well... i just started reading "Hibernate in Action" and learning the
Hibernate framework.
I am not sure if this is true, but it seems like hibernate has this kind
of restriction.
for example, in the case of this example,

private double width;
private double height;

public double getArea() {
return width * height;
}

in order to make the width and height persistent in the database, you will
HAVE to provide the getter and setter (they can have private access
thought, but they have to exist).

My prior reply was meant to confirm that private variable names are
unrestricted. Some setter and getter names may be mandated, but what they
do internally is up to the programmer.

The remark at the top of this message, "might require otherwise", referred
to the possibility that a requirement might be made on the internal name or
type of a private class field. Clearly no.
 
H

hilz

Paul Lutus said:
My prior reply was meant to confirm that private variable names are
unrestricted. Some setter and getter names may be mandated, but what they
do internally is up to the programmer.

The remark at the top of this message, "might require otherwise", referred
to the possibility that a requirement might be made on the internal name or
type of a private class field. Clearly no.

I fully understand what you mean. I know that the java language does not
require anything like that, and it is up to the programmer to name methods
and properties the way they wish. I was just using your example to explain
that certain frameworks (such as Hibernate) might require the names to
follow certain rules.
 
C

Christophe Vanfleteren

hilz said:
Well... i just started reading "Hibernate in Action" and learning the
Hibernate framework.
I am not sure if this is true, but it seems like hibernate has this kind
of restriction.
for example, in the case of this example,

private double width;
private double height;

public double getArea() {
return width * height;
}

in order to make the width and height persistent in the database, you will
HAVE to provide the getter and setter (they can have private access
thought, but they have to exist).

So to answer your question, i think yes, they might be needed by some
framework.
but anyways, since i am still in chapter 3 of the book, i might be wrong!
:)

thanks
hilz

This is not strictly true, newer versions of Hibernate allow direct field
acces, allowing you to skip writing getters/setters for persistent fields.
 
P

P.Hill

hilz said:
I was just using your example to explain
that certain frameworks (such as Hibernate) might require the names to
follow certain rules.

Hibernate only cares about the setter and getters not about any actual member
variables. There even places you can teach hibernate about derived properties.
In your example this might be the "area" property. Sometimes, these apparently
have their uses even to the persistance layer.

-Paul
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top