Java class with set and get method

Discussion in 'Java' started by Gleys, Sep 27, 2004.

  1. Gleys

    Gleys Guest

    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?
     
    Gleys, Sep 27, 2004
    #1
    1. Advertising

  2. Gleys

    kaeli Guest

    In article <>,
    enlightened us with...
    >
    > 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
     
    kaeli, Sep 27, 2004
    #2
    1. Advertising

  3. Gleys

    Eric Sosman Guest

    kaeli wrote:
    > [...]
    > 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;
    }

    --
     
    Eric Sosman, Sep 27, 2004
    #3
  4. Gleys

    Paul Lutus Guest

    Eric Sosman wrote:

    > kaeli wrote:
    >> [...]
    >> 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.

    --
    Paul Lutus
    http://www.arachnoid.com
     
    Paul Lutus, Sep 27, 2004
    #4
  5. Gleys

    Eric Sosman Guest

    Paul Lutus wrote:
    > Eric Sosman wrote:
    >
    >
    >>kaeli wrote:
    >>
    >>>[...]
    >>>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.

    --
     
    Eric Sosman, Sep 27, 2004
    #5
  6. "Eric Sosman" <> wrote in message
    news:cj9t0v$au$...
    >>> 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.
    >


    You're a Sun employee, and you have no better place to ask these questions
    than Usenet?
     
    Mike Schilling, Sep 28, 2004
    #6
  7. Gleys

    Jacob Guest

    LÄÊ»ie Techie wrote:

    > 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.
     
    Jacob, Sep 28, 2004
    #7
  8. Gleys

    Jim Cochrane Guest

    In article <1b66d.20678$>, Mike Schilling wrote:
    >
    > "Eric Sosman" <> wrote in message
    > news:cj9t0v$au$...
    >>>> 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.
    >>

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

    --
    Jim Cochrane;
    [When responding by email, include the term non-spam in the subject line to
    get through my spam filter.]
     
    Jim Cochrane, Sep 28, 2004
    #8
  9. Gleys

    Eric Sosman Guest

    Mike Schilling wrote:
    > "Eric Sosman" <> wrote in message
    > news:cj9t0v$au$...
    >
    >>>> 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.
    >>

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

    --

    Employed by but by no means speaking for Sun Microsystems
     
    Eric Sosman, Sep 28, 2004
    #9
  10. Gleys

    hilz Guest


    > 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
     
    hilz, Sep 28, 2004
    #10
  11. Gleys

    Paul Lutus Guest

    hilz wrote:

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


    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.

    --
    Paul Lutus
    http://www.arachnoid.com
     
    Paul Lutus, Sep 28, 2004
    #11
  12. Gleys

    hilz Guest

    "Paul Lutus" <> wrote in message
    news:...
    > hilz wrote:
    >
    > >
    > >> 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).

    >
    > 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.
    >
    > --
    > Paul Lutus
    > http://www.arachnoid.com
    >


    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.
     
    hilz, Sep 28, 2004
    #12
  13. hilz wrote:

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


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

    --
    Kind regards,
    Christophe Vanfleteren
     
    Christophe Vanfleteren, Sep 28, 2004
    #13
  14. Gleys

    P.Hill Guest

    hilz wrote:

    > 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
     
    P.Hill, Sep 29, 2004
    #14
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Harald Kirsch
    Replies:
    4
    Views:
    2,841
    Harald Kirsch
    Aug 31, 2004
  2. E11
    Replies:
    1
    Views:
    4,788
    Thomas Weidenfeller
    Oct 12, 2005
  3. Pawel_Iks
    Replies:
    3
    Views:
    536
    terminator
    Jul 31, 2007
  4. Greg Hauptmann
    Replies:
    1
    Views:
    110
    Yossef Mendelssohn
    Nov 6, 2008
  5. kuangye
    Replies:
    0
    Views:
    116
    kuangye
    Dec 9, 2009
Loading...

Share This Page