Brick House Java Bean Question

[Dale Seng]

The (unexpected) output is:

Initially...  not set not set
Waist: not set
Chest: not set
 
But...  24 36

Here's the code, which can speak for itself, I think.

public class Pojb {
    
    String waist = "not set";
    String chest = "not set";
    
    Object[] attributes = {waist, chest};
    String[] attributeNames = {"Waist", "Chest"};
 
    public String toString(){
        String result = "";
        for (int i = 0; i < attributes.length; i++){
            result += attributeNames[i] + ": " + attributes[i] + "\n";
        }
        return result;
    }
    
    public String getChest() {return chest;}
    public void setChest(String chest) {this.chest = chest;}
    public String getWaist() {return waist;}
    public void setWaist(String waist) {this.waist = waist;}
 
    public static void main(String[] args) {
        Pojb b = new Pojb();
        System.out.println("Initially...  " + b.getWaist() + " " + b.getChest());
        b.setWaist("24");
        b.setChest("36");
        System.out.println(b);
        System.out.println("But...  " + b.getWaist() + " " + b.getChest());
    }
}

I think I see that because "this.chest = chest;" is really "this.chest = new String(chest);", it means that my reference that's in the array is pointing to an old copy. Fine. Weird, but fine. Now, how does one deal with it? I thought of:

    public String getChest() {return (String)attributes[0];}
    public void setChest(String chest) {attributes[0] = chest;}
    public String getWaist() {return (String)attributes[1];}
    public void setWaist(String waist) {attributes[1] = waist;}

But that's not very nice now, is it?

This is one of those "there must be a better way" things (without removing the key concept here: the array of attributes). They all might not be String objects, by the way.

--Dale--

[Ernest Friedman-Hill]

Originally posted by Dale Seng:

But that's not very nice now, is it?

I'm not sure why you think this is "not nice"; there are two ways to fix your code, and this is one of the two. It's actually the less preferable one, but I could live with it if you had special requirements.

The other one is to get rid of the arrays and loops and lists of names and such drek, and just have

public class Pojb {   
    String waist = "34";
    String chest = "38";
 
    public String toString(){
        return "[Waist: " + waist + " Chest: " + chest + "]";
    }
    
    public String getChest() {return chest;}
    public void setChest(String chest) {this.chest = chest;}
    public String getWaist() {return waist;}
    public void setWaist(String waist) {this.waist = waist;} 
}

The version with the arrays and loops is just plain nasty: hard to understand and hard to change. An awful lot of mess and overhead to introduce just to (presumably) avoid a bit of work in updating the "toString()" method if attributes are added.

[Joel McNary]

Actaully, that way is just fine. That's the point of encapsulation -- it deosn't matter *how* it is implemented, the exposed methods (the getters and setters) will work. The inner workings is just a black box.

[Dale Seng]

Gentlemen: Thank you.

The reason I said it was "not nice" was because Eclipse wouldn't write it for me ;-)

Getting rid of the attributes array isn't really an option because I've got bunches and bunches of attributes that I need to get via EL, so they need a "named getter".

But I wanted to slam data into this, and other beans that extend the same abstract class, by using something along the lines of "attributes[i] = resultSetItem.getObject(i)".

It works the way I have it; I guess it's nice enough.

Thanks again.

--Dale--