help: should valueOf() be static? and naming conventions.

Thread view:

javac - 04 May 2004 23:49 GMT

from LifeForm.java:
private LifeForm() {
System.out.println("LifeForm default constructor..");
}//LifeForm

public static LifeForm valueOf() {
System.out.println("..valueOf..");
return new LifeForm();
// ^^^^^^^^^^^^^^^^^^^^^^^^^
//should this be lifeForm? or what?
}//valueOf

public Location getLocation() {
System.out.println("..getLocation..");
return location;
//^^^^^^^^^^^^^^^^^^^
//should this read this.location? doesn't seem to need that
}//getLocation

public void setLocation(Location location) {
System.out.println("..setLocation..");
this.location = location;
}//setLocation
//seems that this method should be in Location.java, _not_
LifeForm.java

finally, is valueOf() a static or member method? how does it differ
from getInstance(), please?

thanks,

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

Reply to this Message

Christophe Vanfleteren - 05 May 2004 00:10 GMT

> from LifeForm.java:
> private LifeForm() {
[quoted text clipped - 14 lines]
> //should this read this.location? doesn't seem to need that
> }//getLocation

As I said in an earlier post, this.location and location are the same. You
only need to specify this.location if you could have possible confusion,
like in the setLocation method below.

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

Without specifying this, the compiler would not know which location variable
you mean. Just avoid it by giving the parameter of setLocation another
name.

> //seems that this method should be in Location.java, _not_
> LifeForm.java

No it doesn't, since it assigns a Location to a Lifeform, and the Location
is a member field of Lifeform.

> finally, is valueOf() a static or member method? how does it differ
> from getInstance(), please?

Nothing is inherently static or not about a method name. It is static if you
declare it to be static, that's it. In your example, it should definitely
be static, since it doesn't need any instance data.

Methods called getInstance() are also about always static because they
usually act as a factory method (method that is meant to create objects of
a certain type). getInstance() is the name most often used when using
singletons (classes that should only have 1 instance at a time).

But there is no inherent difference between valueOf() and getInstance().
They are just method names you make up. You could name them foo() and bar()
if you'd want to.
It is not like a method that is defined in the class java.lang.Object (like
hashcode(), toString(), ...), which have very specific behavior.

As a tip, in earlier posts, you mentioned the book "Effective Java". I hope
you do realise that this is not a "learning java" kind of book. It is more
meant to explain/rationalise some concepts/designs of Java and provide some
best practices. If you want to actually learn Java, start with the Java
tutorial. Because as it seems now, you're only getting extra confusion from
some of the concepts explained in the book.

http://java.sun.com/docs/books/tutorial/

Signature

Kind regards,
Christophe Vanfleteren

Reply to this Message

VisionSet - 05 May 2004 12:39 GMT

> As I said in an earlier post, this.location and location are the same. You
> only need to specify this.location if you could have possible confusion,
[quoted text clipped - 4 lines]
>> this.location = location;
>> }//setLocation

I think the explicit use of 'this' is fairly standard practise in these
situations.
Isn't it even enforced in C#?
Or has this 'standard' practise arisen purely because of other languages
standards?

--
Mike W

Reply to this Message

Ryan Stewart - 05 May 2004 23:57 GMT

> > As I said in an earlier post, this.location and location are the same. You
> > only need to specify this.location if you could have possible confusion,
[quoted text clipped - 10 lines]
> Or has this 'standard' practise arisen purely because of other languages
> standards?

In that particular situation, it's not a "practice". It's a necessity. The
method parameter shadows the instance variable, so you must use "this" to
access the class member.

Reply to this Message

VisionSet - 06 May 2004 09:11 GMT

> > > As I said in an earlier post, this.location and location are the same.
> You
[quoted text clipped - 15 lines]
> method parameter shadows the instance variable, so you must use "this" to
> access the class member.

Yes, of course! I mean as opposed to a differently named local variable.

--
Mike W

Reply to this Message

javac - 06 May 2004 23:35 GMT

[..]

> But there is no inherent difference between valueOf() and getInstance().
> They are just method names you make up. You could name them foo() and bar()
> if you'd want to.
> It is not like a method that is defined in the class java.lang.Object (like
> hashcode(), toString(), ...), which have very specific behavior.

it's not that there's anything inherently different, my question is
more about conventions.

> As a tip, in earlier posts, you mentioned the book "Effective Java". I hope
> you do realise that this is not a "learning java" kind of book. It is more
[quoted text clipped - 4 lines]
>
> http://java.sun.com/docs/books/tutorial/

yeh, i read more than _one_ book, of course! rather than say
"confusing" i'd say "challenging" :) i have some more books coming
from the library...

thanks,

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

Reply to this Message

Ryan Stewart - 05 May 2004 05:31 GMT

> from LifeForm.java:
> private LifeForm() {
[quoted text clipped - 7 lines]
> //should this be lifeForm? or what?
> }//valueOf

What's lifeForm? Why would this be that?

> public Location getLocation() {
> System.out.println("..getLocation..");
> return location;
> //^^^^^^^^^^^^^^^^^^^
> //should this read this.location? doesn't seem to need that
> }//getLocation

Assuming location is a member of LifeForm, referencing "location" is
identical to "this.location".

> public void setLocation(Location location) {
> System.out.println("..setLocation..");
> this.location = location;
> }//setLocation
> //seems that this method should be in Location.java, _not_
> LifeForm.java

Why on earth would it be there? You don't set a Location's location. You set
a LifeForm's location.

> finally, is valueOf() a static or member method? how does it differ
> from getInstance(), please?

You've misunderstood a lot of what I said in the other thread. It seems that
you need to spend some time with a good Java/OOP book. The way you're using
valueOf, it must be static. I disagree with how you're using it though, and
with its name. To see how valueOf is typically used, take a look in the API
specs at classes like String, Integer, Float, etc. There should be an
example of typical getInstance method in java.util.Calendar, IIRC. Also,
please provide compilable code when you post.

Reply to this Message

javac - 06 May 2004 23:11 GMT

[..]

> You've misunderstood a lot of what I said in the other thread. It seems that
> you need to spend some time with a good Java/OOP book. The way you're using
[quoted text clipped - 3 lines]
> example of typical getInstance method in java.util.Calendar, IIRC. Also,
> please provide compilable code when you post.

you've got my attention in that you disagree with how i'm using
valueOf and it's name.

also in the other thread, but maybe better here because of the
subject, or whatever:

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

i think i'm right ;) but certainly a topic worthy of settling.

thanks,

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

Reply to this Message

Ryan Stewart - 07 May 2004 00:40 GMT

> [..]
> > You've misunderstood a lot of what I said in the other thread. It seems that
[quoted text clipped - 39 lines]
>
> i think i'm right ;) but certainly a topic worthy of settling.

First, note that neither of these methods are necessarily tied to the
factory concept. In the core classes, valueOf is used exclusively (unless
I'm mistaken) like a conversion constructor in C++, if you're familiar with
that. Basically, it takes one class (or type, more accurately) and converts
it to another. For instance, in class Boolean:
public static Boolean valueOf(String s)

This takes an object of the String class and converts it to an object of the
Boolean class. The sample you gave above I would consider shaky. It does
more or less follow the conversion constructor idea, in that a complex
number is the "value of" a real and imaginary component. However, I am
unaware of any reason to implement it in such a way, and aware of at least
one reason to not: efficiency. Why add an unnecessary method call?
Constructors are perfectly useable without hiding them under a method.

The use of the getInstance method is not so clear-cut. First, notice that it
may or may not take parameters, so you're not entirely correct on that
count. A fairly common use of the getInstance method is in abstract classes.
Obviously you can't instantiate them directly, but you may wish to implement
a mechanism in an abstract base class that will create instances of some
subclass. If you feel like a bit of reading, take a look at the J2EE DAO
design pattern:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.ht
ml

Specifically, look at the code in Example 9.2. By coincidence, it's a
factory class. The method is named getDAOFactory, but could just as easily
be getInstance (would have been a better choice, IMHO).

Reply to this Message

javac - 08 May 2004 22:12 GMT

[..]

> First, note that neither of these methods are necessarily tied to the
> factory concept. In the core classes, valueOf is used exclusively (unless
> I'm mistaken) like a conversion constructor in C++, if you're familiar with
> that. Basically, it takes one class (or type, more accurately) and converts
> it to another. For instance, in class Boolean:
> public static Boolean valueOf(String s)

"This static factory...translates a boolean primitive value into a
Boolean object reference"
effective java, p5. ok.

> This takes an object of the String class and converts it to an object of the
> Boolean class. The sample you gave above I would consider shaky. It does
[quoted text clipped - 3 lines]
> one reason to not: efficiency. Why add an unnecessary method call?
> Constructors are perfectly useable without hiding them under a method.

there are advantages, also.

> The use of the getInstance method is not so clear-cut. First, notice that it
> may or may not take parameters, so you're not entirely correct on that
[quoted text clipped - 9 lines]
> factory class. The method is named getDAOFactory, but could just as easily
> be getInstance (would have been a better choice, IMHO).

i'm still reading! problem is, i don't have a frame of reference for
much of that.

javac@mail.com

Reply to this Message

Ryan Stewart - 09 May 2004 03:40 GMT

> > This takes an object of the String class and converts it to an object of the
> > Boolean class. The sample you gave above I would consider shaky. It does
[quoted text clipped - 5 lines]
>
> there are advantages, also.

Advantages to what? Hiding the constructor? In some circumstances there are,
but not in doing it just to do it.

Reply to this Message

help: should valueOf() be static? and naming conventions.

Free Magazines