help: object LifeForm composed of immutable object Location. how do I give a LifeForm a different Location object?

Thread view:

javac - 03 May 2004 00:45 GMT

some code snippets:

LifeForm.java method:
-----------------
public void setLocation(int x, int y, int z) {
System.out.println("..setLocation..");
location.valueOf(x, y, z);
}//setLocation

VectorOfLifeForms.java main:
-------------------------

public static void main(String[] args) {
System.out.println("VectorOfLifeForms main..");

System.out.println("FILLING VECTOR");
for (int i=0; i<MAX_LIFE; i++) {
createLife();
}//for

System.out.println("MOVING LIFE FORMS");
for (int i=0; i<MAX_LIFE; i++) {
lifeForm = (LifeForm)vectorOfLifeForms.get(i);
lifeForm.setLocation(1, 1, 1);
}//for

System.out.println("******************************");
System.out.println("******************************");
System.out.println("******************************");
System.out.println("CHECKING IF LIFE FORMS WERE MOVED");

for (int i=0; i<MAX_LIFE; i++) {
lifeForm = (LifeForm)vectorOfLifeForms.get(i);
lifeForm.toString();
}//for

System.out.println("..VectorOfLifeForms main..done");
}//main

sorry if the main method is a bit verbose, but there it is. why don't
any of the life forms actually have new location objects with values
of 1 for fields x,y,z?

javac@mail.com
http://www.geocities.com/cjavacjava/src/readme.txt
2 may 2004

Reply to this Message

Ryan Stewart - 03 May 2004 03:26 GMT

> some code snippets:
>
[quoted text clipped - 38 lines]
> any of the life forms actually have new location objects with values
> of 1 for fields x,y,z?

First, please put relevant information in the body of your message and just
use a brief description for the subject. Now, from the looks of it, you
should take another look at object oriented programming. You claim that a
LifeForm has a Location object, which is immutable. Something like:

public class Location {
private int x;
private int y;
private int z;

public Location(int x, int y, int z) {
this.x = x;
this.y = y;
this.z = z;
}
}

This Location class produces immutable objects because after the object is
constructed, there is no way to change its x, y, and z values. That's what
immutable means. As for LifeForm:

public class LifeForm {
private Location location;

public Location getLocation() {
return this.location;
}

public void setLocation(Location location) {
this.location = location;
}

These are basic accessor methods that allow you to get or set a LifeForm's
location. You would use them like this:

// Inside some method
LifeForm alien = new LifeForm();
alien.setLocation(new Location(1, 2, 3));
Location alienLocation = alien.getLocation();
Bomb nuke = new Bomb();
nuke.setLocation(alienLocation);

Obviously I took a couple of creative liberties there. The point is that
since a Location is immutable, you can safely assign the same Location to
two different objects. If a Location could be modified, and you assign one
Location to both the alien and the bomb, then when that Location is
modified, it affects both bomb and alien (so the alien can never get away
from the bomb :). Obviously if things move around a lot, you're creating
some overhead by constructing and throwing away a bunch of Location objects.

Reply to this Message

javac - 03 May 2004 22:05 GMT

[..]

> // Inside some method
> LifeForm alien = new LifeForm();
[quoted text clipped - 10 lines]
> from the bomb :). Obviously if things move around a lot, you're creating
> some overhead by constructing and throwing away a bunch of Location objects.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

agreed, but performance isn't a present concern. absolutely, i'm
trying to wrap my head around OO programming. i _want_ to be
"constructing and throwing away a bunch of Location objects," just
dunno how to do that :)

here's what I presently have:
private static void moveLife(int i) {
System.out.println("..moveLife..");
lifeForm = (LifeForm)VECTOR_OF_LIFE_FORMS.get(i);
lifeForm.setLocation(1, 1, 1);
VECTOR_OF_LIFE_FORMS.set(i, lifeForm);
}//moveLife

I notice you use
alien.setLocation(new Location(1, 2, 3));
while i use
lifeForm.setLocation(1, 1, 1);

clearly different. I'll have to try your suggestion at home. please
note, i'm using static factory methods, so i wouldn't use "new," but
still food for thought.

javac@mail.com
source code: http://www.geocities.com/cjavacjava/
(now with actual links!)

Reply to this Message

Ryan Stewart - 04 May 2004 02:34 GMT

> [..]
> > // Inside some method
[quoted text clipped - 11 lines]
> > from the bomb :). Obviously if things move around a lot, you're creating
> > some overhead by constructing and throwing away a bunch of Location objects.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> agreed, but performance isn't a present concern. absolutely, i'm
> trying to wrap my head around OO programming. i _want_ to be
> "constructing and throwing away a bunch of Location objects," just
> dunno how to do that :)

By "constructing" I mean creating new objects, like "new LifeForm()" or "new
Location()" or "new StringBuffer()". The new operator creates an object. By
"throwing away" I mean no longer using in any of your code. For example:
Location l;
l = new Location(1, 2, 3);
l = new Location(4, 5, 6);

I've first declared a variable "l" (that's a lowercase 'L'). Then I store in
it a reference to a new Location object with coordinates 1, 2, 3. Then I
store in it a reference to another Location object with coords 4, 5, 6. The
first location object is lost and will (might) be garbage collected at some
later time because the code no longer has any way to reach that object.

> here's what I presently have:
> private static void moveLife(int i) {
[quoted text clipped - 12 lines]
> note, i'm using static factory methods, so i wouldn't use "new," but
> still food for thought.

From your original post:
public void setLocation(int x, int y, int z) {
System.out.println("..setLocation..");
location.valueOf(x, y, z);
}//setLocation

What exactly is "location", and what is that valueOf method supposed to do
to it? If "location" is a Location object, and the valueOf method is
supposed to change the contents of it, then a Location is *not* immutable,
as you claim. If Locations truly *are* immutable, then you must create a new
Location object in order to "move" a LifeForm.

Reply to this Message

javac - 05 May 2004 00:04 GMT

[..]

> From your original post:
> public void setLocation(int x, int y, int z) {
[quoted text clipped - 7 lines]
> as you claim. If Locations truly *are* immutable, then you must create a new
> Location object in order to "move" a LifeForm.

from Location.java:
public void setLocation(Location location) {
System.out.println("..setLocation..");
this.location = location;
}//setLocation

valueOf() is a static factory method, returning a new instance given
whatever parameters are passed to it. location objects are immutable.

passing setLocation() an object (and not integers) and using the
"this" key-word seem to have solved my immediate problems. it's doing
what i want it to, or so i think....

please keep in mind, when i say "location is immutable," that's, of
course, open to being challenged :) in fact, please do challenge it.

see /src/ecosystem7/ if you'd like to see the current version :)

thanks,

javac@mail.com
http://www.geocities.com/cjavacjava/

Reply to this Message

Ryan Stewart - 05 May 2004 02:51 GMT

> [..]
> > From your original post:
[quoted text clipped - 14 lines]
> this.location = location;
> }//setLocation

You mean from LifeForm, right?

> valueOf() is a static factory method, returning a new instance given
> whatever parameters are passed to it. location objects are immutable.

Why? Why not use the constructors? That's what they're for.

> passing setLocation() an object (and not integers) and using the
> "this" key-word seem to have solved my immediate problems. it's doing
> what i want it to, or so i think....

That part of your code appears correct. Your LifeForm has a Location, and to
change its Location, you create a new location object and assign it to the
LifeForm (in a manner of speaking).

> please keep in mind, when i say "location is immutable," that's, of
> course, open to being challenged :) in fact, please do challenge it.

What you have now is immutable. Once a Location is created, its contents
can't be changed.

> see /src/ecosystem7/ if you'd like to see the current version :)

I did that :) Several other things catch my eye. Here are a few:
1) Ignoring the fact that you're using methods to create instances when you
don't need to, the name of the methods leaves a lot to be desired. "valueOf"
is a commonly used method from the core language. A more standard method for
getting instances of objects is "getInstance". (Imagine that.)

2) From Location.java:
********************
private final int x;
private final int y;
private final int z;
********************
There is no reason for those to be final. They're inaccessible from
outside Location, so you don't have to worry about other people modifying
them.

3) From LifeForm.java:
********************
private Location location = Location.valueOf(0, 0, 0);

private LifeForm() {
System.out.println("LifeForm default constructor..");
}//LifeForm
********************
You'll probably find it more practical like this:
********************
private Location location;

private LifeForm(Location location) {
System.out.println("LifeForm default constructor..");
this.location = location;
}//LifeForm
********************
That will allow you to set a LifeForm's position upon creation.

4) In ListOfLifeForms, you make this declaration:
private static LifeForm lifeForm;

Then you use your "lifeForm" variable in several of your methods. This
is very bad form. Get rid of this member variable and declare a LifeForm
variable within the methods as needed.

5) Your ListOfLifeForms in general is confused and not well formed. You have
too much staticness (if that's a word). It also is not what its name
implies. It is your main program, and it *contains* a list of life forms,
but is not one itself. I assume you're currently working on this class,
because the line "LIST_OF_LIFE_FORMS.toString();" does nothing (if you
hadn't noticed yet). Even if it did, it probably wouldn't do what you're
expecting it to. Mainly, you seem to have forgotten all about object
oriented programming when writing this class. It looks more like an old
procedural program than anything OO. There's some other things, but I don't
have time at the moment. Maybe later.

Reply to this Message

javac - 05 May 2004 23:38 GMT

[..]

> > see /src/ecosystem7/ if you'd like to see the current version :)
> >
[quoted text clipped - 50 lines]
> procedural program than anything OO. There's some other things, but I don't
> have time at the moment. Maybe later.

ah, yes. thank you. i've printed out your message (the ultimate
accolade) and'll take a closer look at home. you're not the first
with some of your criticisms, but thank you.

javac@mail.com
http://www.geocities.com/cjavacjava/

Reply to this Message

Roedy Green - 06 May 2004 00:12 GMT

>There is no reason for those to be final.

Final is a documentation aid. It says "I compute these once and they
stay fixed. You don't have to worry about some sneaky code somewhere
changing them. The compiler won't allow it.

Or it could say, "this code depends upon the values not changing. If
they do, its on your head to modify the code to deal with it."

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Reply to this Message

javac - 06 May 2004 22:59 GMT

[..]

> Why? Why not use the constructors? That's what they're for.

partly for novelty and experimentation. partly to rule out extending
the class's, in favor of composition.

[..]

> I did that :) Several other things catch my eye. Here are a few:
> 1) Ignoring the fact that you're using methods to create instances when you
> don't need to, the name of the methods leaves a lot to be desired. "valueOf"
> is a commonly used method from the core language. A more standard method for
> getting instances of objects is "getInstance". (Imagine that.)

from http://java.sun.com/docs/books/effective/ pg 68:

//Immutable class with static factories instead of constructors
public class Complex {
private final float re;
private final float im;

private Complex(float re, float im) {
this.re = re;
this.im = im;
}

public static Complex valueOf(float re, float im) {
return new Complex(re, im);
}
// ... // remainder unchanged
}

genuinely, i don't get it. this sample code indicates i'm following
the naming conventions, yet you're certainly not alone in saying i'm
not.

as far as i can tell, valueOf() is used when values are passed to the
factory, getInstance() is used if not. yes/no/other? naming
conventions seem crucial to me, unless no one ever looks at anyone
elses code ;)

[..]

3.)

> You'll probably find it more practical like this:
> ********************
[quoted text clipped - 6 lines]
> ********************
> That will allow you to set a LifeForm's position upon creation.

i think so, too :) i'll give it a try. i'll overload the constructor.

> 4) In ListOfLifeForms, you make this declaration:
> private static LifeForm lifeForm;
>
> Then you use your "lifeForm" variable in several of your methods. This
> is very bad form. Get rid of this member variable and declare a LifeForm
> variable within the methods as needed.

done. thank you :)

> 5) Your ListOfLifeForms in general is confused and not well formed. You have
> too much staticness (if that's a word). It also is not what its name
[quoted text clipped - 6 lines]
> procedural program than anything OO. There's some other things, but I don't
> have time at the moment. Maybe later.

i've broken it into three seperate classes. the ListOfLifeForms, then
an assortment of static methods which operate on that list, then a
"driver" class. hopefully, a _bit_ more OO. although, it's nothing
_different_. maybe just easier on the eyes?

(i did patch up the toString() methods)

can't decide, nor implement, making ListOfLifeForms a single list.
not sure if it should extend Vector and implement List, or what...nor
how to do that, if so. there should only ever be _one_ list of life
forms to my thinking. and, not sure it shouldn't be a set of life
forms, since each life form is, uh, unique (never mind clones). of
course, i'd have to add an Identification or ID object to get the set
working.

thanks again,

javac@mail.com
http://www.geocities.com/cjavacjava/

Reply to this Message

help: object LifeForm composed of immutable object Location. how do I give a LifeForm a different Location object?

Free Magazines