Re: mutate an object or create a new one?

From:

"Oliver Wong" <owong@castortech.com>

Newsgroups:

comp.lang.java.programmer

Date:

Tue, 24 Oct 2006 18:26:19 GMT

Message-ID:

<fVs%g.71499$E67.29844@clgrps13>

"Ingo R. Homann" <ihomann_spam@web.de> wrote in message
news:453e20ac$0$5729$9b4e6d93@newsspool3.arcor-online.net...

Hi,

concerning your problem of recycling objects, my opinion is clear:

Do NOT recycle objects. It *may* speed up you app in some cases (while it
may slow down your app in other cases). Write clean and readable code and
choose the right data structures and algorithms. If your platform does not
have enough resources to properly run your application, recycling objects
will not help very much. In 99% there are more disadvantages than
advantages.

To your other question ("const" (which I am missing as well) vs
"mutability"):

I have not tested it in a productive environment, but an approach would by
something like that:

class UnmodifiableInt {
  protected int i;
  public int getValue() {
   return i;
  }
}

class ModifiableInt extends UnmodifiableInt {
  public void setValue(int i) {
   this.i=i;
  }
}

    I recommend having 3 classes, instead of 2 (or 2 classes, and 1
interface):

interface Int {
  public int getValue();
}

final class UnmodifiableInt implements Int {
  protected int i;
  public int getValue() {
    return i;
  }
}

final class ModifiableInt implements Int {
  protected int i;
  public int getValue() {
    return i;
  }
  public void setValue(int i) {
    this.i=i;
  }
}

    The problem with the 2-class design is that it fails the IS-A test of
inheritance: that is, it should not be the case than a ModifiableInt IS-A
UnmodifiableInt. So you should not be able to use a ModifableInt anywhere an
UnmodifiableInt is expected.

    - Oliver