Home > Archive > Java Help > July 2004 > <blah> cannot be referenced from a static context
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
<blah> cannot be referenced from a static context
|
|
| thufir.hawat@mail.com 2004-07-22, 3:58 pm |
| I'm always getting this error; by trial and error I kludge my way out of
it. Definitely it's due to some conceptual holdovers from FORTRAN, but
why do I keep making the same mistake?
thanks,
Thufir Hawat
| |
| Eric Sosman 2004-07-22, 3:59 pm |
| thufir.hawat@mail.com wrote:
> I'm always getting this error; by trial and error I kludge my way out of
> it. Definitely it's due to some conceptual holdovers from FORTRAN, but
> why do I keep making the same mistake?
You repeat the mistake because you've been taking too
much spice. ;-)
Perhaps you're not clear on the distinction between
a "static context" and a -- well, I don't know of any
official term and "non-static context" sounds awfully clumsy,
so let's call it an "object context" for the moment, shall we?
An object context is always associated with a particular
object instance. The built-in identifier `this' refers to
that associated object, and can be used to obtain access to
the object's member variables and methods. (It can usually
be omitted, in one of Java's few useful tersenesses, but
this is just syntactic sugar: If you mention a member variable
without qualification, it's shorthand for `this.variable'.)
The crucial thing is that `this' exists and refers to a
particular object. (In a constructor there's another use
for the `this' keyword, but let's not worry about it.)
A static context is associated with a class, not with
any particular object. There is no `this' in a static
context, because there is no object for it to refer to.
You can't write `this.variable' explicitly because there
is no `this', and you can't just write `variable' because
that would be shorthand for `this.variable' and you're
right back where you started. Or to put it another way:
if every object of the class has its own copy of `variable',
which of those hundreds of copies would you be referring
to in a static context that's not associated with any of
the objects? Or suppose the static context is executing
when no objects at all have yet been created; what would
it mean to refer to a `variable' that doesn't even exist?
Now, if you've got an explicit reference to some object,
a static context can use that reference explicitly to refer
to that object's variables and methods -- but the reference
must be explicit as in `that.variable' because there's no
implied `this' to disambiguate things. Similarly, in an
object context you can use an explicit reference to refer
to the variables and methods of an object other than the
implied `this' object; again, the reference must be explicit
because if you didn't supply one `this.' would be implied.
*Any* context can use an explicit object reference (if it
can get hold of one) to manipulate an object, but only in
an object context can you use the implied `this'.
What are the static contexts? Any method declared with
the `static' keyword is a static context; it belongs to the
class as a whole and not to any particular object. An
initializer clause with the `static' keyword is a static
context. The initializing expression for a `static' variable
is a static context. Maybe the experts can fill in a few
others.
What are the object contexts? Any method declared without
`static' is an object context; it belongs to its associated
object and can refer to it as `this' (often implied). A
constructor is an object context; `this' is the object being
constructed. An initialization clause without `static' is
an object context, and so is the initialization expression
for a non-`static' member variable. Again, the experts may
be able to expand this list.
Hope this helps.
--
Eric.Sosman@sun.com
| |
| Ryan Stewart 2004-07-23, 8:57 am |
| "Eric Sosman" <Eric.Sosman@sun.com> wrote in message
news:40FFD8E6.8090902@sun.com...
> thufir.hawat@mail.com wrote:
> Perhaps you're not clear on the distinction between
> a "static context" and a -- well, I don't know of any
> official term and "non-static context" sounds awfully clumsy,
> so let's call it an "object context" for the moment, shall we?
>
"non-static context"
| |
| Eric Sosman 2004-07-23, 3:58 pm |
| Ryan Stewart wrote:
> "Eric Sosman" <Eric.Sosman@sun.com> wrote in message
> news:40FFD8E6.8090902@sun.com...
>
>
> "non-static context"
Not very non-inelegant, is it?
--
Eric.Sosman@sun.com
| |
| Grant Wagner 2004-07-23, 3:58 pm |
| thufir.hawat@mail.com wrote:
> I'm always getting this error; by trial and error I kludge my way out of
> it. Definitely it's due to some conceptual holdovers from FORTRAN, but
> why do I keep making the same mistake?
What error?
Trial and error is a bad way to learn how to program.
Did you refer to non-existent errors and try random things to make stuff
work in FORTRAN too?
Why do you keep making the same mistake? Maybe you're just stupid.
Now that I've answered all the questions you did ask, I'll answer the ones
you didn't:
<url: http://mindprod.com/jgloss/gettingstarted.html />
<url: http://mindprod.com/jgloss/tutorials.html />
| |
| Roedy Green 2004-07-23, 3:58 pm |
| On Fri, 23 Jul 2004 06:55:53 -0500, "Ryan Stewart"
<zzanNOtozz@gSPAMo.com> wrote or quoted :
[color=darkred]
I am pushing for the adoption of the term "instance" to mean
"non-static".
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Roedy Green 2004-07-23, 3:58 pm |
| On Fri, 23 Jul 2004 15:36:33 GMT, Grant Wagner
<gwagner@agricoreunited.com> wrote or quoted :
>Trial and error is a bad way to learn how to program.
I have experimented with teaching techniques and I find that if you
can get people USED to trial and error at the beginning, to treat the
programming enterprise as a puzzle that you are NOT supposed to just
effortlessly crack, this experimental attitude holds them in good
stead.
In the real world, the documentation is often over your head, missing,
misleading or out of date. What then? If you are going to succeed,
tenacity and trial and error will get you through.
On the other hand, some people get in the habit of ignoring perfectly
good docs and waste a lot of theirs or other people's time. I suppose
it depends who you are talking to which sort of encouragement to give.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Grant Wagner 2004-07-23, 3:58 pm |
| Roedy Green wrote:
> On Fri, 23 Jul 2004 15:36:33 GMT, Grant Wagner
> <gwagner@agricoreunited.com> wrote or quoted :
>
>
> I have experimented with teaching techniques and I find that if you
> can get people USED to trial and error at the beginning, to treat the
> programming enterprise as a puzzle that you are NOT supposed to just
> effortlessly crack, this experimental attitude holds them in good
> stead.
Trial and error backed by critical thinking and logic. Not trial and error
like trying to assemble a picture puzzle where you fit pieces together by
cutting off the tabs that don't have a receiving slot.
I have seen people program where they slap some loops, conditions and
assignments together. Randomly change the order of the bits and stop when
they stop getting errors and get a result they like for the one piece of
test data they are trying. This is not bad in and of itself, but at this
point they seem to have little interest in learning or understanding why
and how what they have done works, and can't understand why what they have
done fails to produce the desired output the moment they introduce some
change to either the input or the code itself.
In other words, they don't learn from their trial and error, they just
continue to attack every problem with the same nonsensical technique,
because it has worked so well for them in the past.
This is the attitude I saw in the OP. He "fiddles around" until he stops
getting the error. He has received the error in the past, he receives the
error now, and will continue to receive the error intermittently in the
future until he stops long enough to learn _why_ he is getting the error
and what _specifically_ he needs to do to avoid it in the future. Until he
learns from his mistakes.
Mentioning the fact that he is a former FORTRAN programmer was, I think,
an attempt to "impress" us. But I was unimpressed by an approach to Java
that an experienced programmer should have abandoned a long time ago.
> In the real world, the documentation is often over your head, missing,
> misleading or out of date. What then? If you are going to succeed,
> tenacity and trial and error will get you through.
However in this case, the following search: <url:
http://www.google.com/search? q=can...+con
text
/>
turns up as it's first match: <url:
http://www.experts-exchange.com/Pro...Q_20771025.html />
which explains both the problem, and the solution.
> On the other hand, some people get in the habit of ignoring perfectly
> good docs and waste a lot of theirs or other people's time. I suppose
> it depends who you are talking to which sort of encouragement to give.
I will give plenty of encouragement to someone I see genuinely trying. If
the OP had provided an example of the sort of code he writes and asked a
specific question like "whenever I do A, I get error B and I don't really
understand why. I have read some tutorials, but I don't really understand
them, could someone point me to an explanation of the error and an example
of how I can change my code to avoid the error in a way I might be able to
understand?" I'd have been much less condescending.
--
Grant Wagner <gwagner@agricoreunited.com>
| |
| Roedy Green 2004-07-23, 3:58 pm |
| On Fri, 23 Jul 2004 18:13:56 GMT, Grant Wagner
<gwagner@agricoreunited.com> wrote or quoted :
>In other words, they don't learn from their trial and error, they just
>continue to attack every problem with the same nonsensical technique,
>because it has worked so well for them in the past.
This is the approach genetic evolution uses, so it is no surprise some
of its creations do too.
I think the essential problem is stimulating curiosity. My parents
highly valued curiosity and went to absurd lengths to avoid crushing
mine.
Some people were severely punished for their curiosity. They will have
a difficult time with computers. On the other hand, they will have
less trouble than I getting sidetracked by every interesting thing.
What do we do to rekindle that curiosity? We ask intriguing questions
and reward with praise when the newbies figure things out on their
own.
I fear your grumpy dad approach to newbies just keeps them stuck in
their fear of making mistakes. To experiment, you must first get rid
of your sense of shame for not getting it right the first time.
Teaching adults can be so frustrating. They are SO humiliated to make
an error they REFUSE to try something that MIGHT work. They want an
iron-clad guarantee it will work before they so much as hit a key. I
sometimes feel like strangling them.
Most people can't just sit down and reason. They have to just do
repetition repetition repetition, and gradually the patterns begin to
sink in. They need a certain comfort level with the mechanics before
they feel comfortable enough to start thinking more abstractly.
This is one reason I suggest people do bottom up coding when they are
stuck. Creating a little method that might come in useful is also a
tool to think more abstractly about the overall problem.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| thufir.hawat@mail.com 2004-07-23, 3:58 pm |
| On Fri, 23 Jul 2004, Grant Wagner wrote:
gee, I really push your buttons Grant, don't I?
[..]
> I have seen people program where they slap some loops, conditions and
> assignments together. Randomly change the order of the bits and stop when
> they stop getting errors and get a result they like for the one piece of
> test data they are trying. This is not bad in and of itself, but at this
> point they seem to have little interest in learning or understanding why
> and how what they have done works, and can't understand why what they have
> done fails to produce the desired output the moment they introduce some
> change to either the input or the code itself.
I thought it was clear I was referring to the fact that I'm having
difficulty transitioning to the OO paradigm, not dealing with loops or
logic intricacies (sp).
By definition, kludge's are to be avoided, particularly with regard to any
design issues. Hence, my question.
> In other words, they don't learn from their trial and error, they just
> continue to attack every problem with the same nonsensical technique,
> because it has worked so well for them in the past.
If I weren't trying to learn from my errors, why would I ask what this
error indicates?
> This is the attitude I saw in the OP. He "fiddles around" until he stops
> getting the error. He has received the error in the past, he receives the
> error now, and will continue to receive the error intermittently in the
> future until he stops long enough to learn _why_ he is getting the error
> and what _specifically_ he needs to do to avoid it in the future. Until he
> learns from his mistakes.
yes, I've had the error before and I expect to get the same error again.
> Mentioning the fact that he is a former FORTRAN programmer was, I think,
> an attempt to "impress" us. But I was unimpressed by an approach to Java
> that an experienced programmer should have abandoned a long time ago.
I never claimed to be an experience programmer. AFAIK there's quite a
difference between procedural v. OO programming. Giving some background
info indicating why I might be making this mistake seems reasonable to me.
[..]
>
> However in this case, the following search: <url:
> http://www.google.com/search? q=can...+con
text
> />
> turns up as it's first match: <url:
> http://www.experts-exchange.com/Pro...Q_20771025.html />
> which explains both the problem, and the solution.
Thank you, I'll take a look this evening.
[..]
> I will give plenty of encouragement to someone I see genuinely trying. If
> the OP had provided an example of the sort of code he writes and asked a
> specific question like "whenever I do A, I get error B and I don't really
> understand why. I have read some tutorials, but I don't really understand
> them, could someone point me to an explanation of the error and an example
> of how I can change my code to avoid the error in a way I might be able to
> understand?" I'd have been much less condescending.
As you've stated, it's a conceptual problem, not really fixed by tweaking,
moving some lines around, etc (all the "techniques" you derided above).
When I posted the original question I thought I could quickly fix it;
later I posted the troublesome code in a different thread--clearly I
should've posted it in this thread. I went out last night and haven't
done a lick of work on it since then, unfortunately.
IMHO asking a question is a great way to figure things out. Even if no
one were to respond to my question, at least I've identified the problem
for my own sake. If peopele are willing to share some knowledge, so much
the better.
"..change the code.." doesn't really address the problem, since it's
conceptual, IMHO. however, you can see my other thread by a similar name,
if you like.
> --
> Grant Wagner <gwagner@agricoreunited.com>
>
>
Thufir Hawat
| |
| Tor Iver Wilhelmsen 2004-07-23, 8:56 pm |
| Roedy Green <look-on@mindprod.com.invalid> writes:
> I am pushing for the adoption of the term "instance" to mean
> "non-static".
But that is also too vague: Objects ("instances") are not as much
instantiated classes as data structures defined by the class.
Classes have
1) Metadata defining how the related data structure should be
constructed,
2) Methods; Except for the non-virtual nature of static methods, an
"instance" method can be thought of as a "static" method that takes
an implicit parameter: a pointer to such a data structure.
3) Type information; inheritance tree, interfaces implemented etc.
That an "instance" is associated with a class/type is important to the
compiler and the runtime (casting): The data structure does not know
nor care.
The term "an instance of a class" would instead fit a given "class
object" loaded by a particular ClassLoader; So if the same class' code
is loaded by two different classloaders, you get two instances of the
class.
| |
| Roedy Green 2004-07-23, 8:56 pm |
| On 23 Jul 2004 22:37:29 +0200, Tor Iver Wilhelmsen
<tor.iver.wilhelmsen@broadpark.no> wrote or quoted :
>But that is also too vague: Objects ("instances") are not as much
>instantiated classes as data structures defined by the class.
the bottom line for you then is "non-static"?
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Tor Iver Wilhelmsen 2004-07-23, 8:56 pm |
| Roedy Green <look-on@mindprod.com.invalid> writes:
> the bottom line for you then is "non-static"?
I'd say it's descriptive enough.
| |
| Ryan Stewart 2004-07-24, 3:56 am |
| <thufir.hawat@mail.com> wrote in message
news:Pine.GSO.4.43.0407231138040.2570-100000@earth...
> On Fri, 23 Jul 2004, Grant Wagner wrote:
> yes, I've had the error before and I expect to get the same error again.
>
I think part of the point is that you should not expect that. You should
learn the language basics and see why this is a very common newbie
problem--speaking of which, did you Google it before you posted? If so, you
should have found a mountain of information on this topic--and why you
should expect to *not* see it any more in your code after you understand a
few simple principles.
| |
| thufir.hawat@mail.com 2004-07-28, 9:08 pm |
| On Fri, 23 Jul 2004, Ryan Stewart wrote:
[..]
> I think part of the point is that you should not expect that. You should
> learn the language basics and see why this is a very common newbie
> problem--speaking of which, did you Google it before you posted? If so, you
> should have found a mountain of information on this topic--and why you
> should expect to *not* see it any more in your code after you understand a
> few simple principles.
I found some material, but not much that was helpful. As I already knew
the solution I admittedly didn't look that hard. The frustration for me
is that to make things compile a utility class is needed, but *why*
escapes me. Until I understand the error message I expect to see it
again--I fixed the error message by rote.
ThingTestDriver checks to see if the the other classes clash:
public class ThingTestDriver {
private ThingTestDriver() {
System.out.println("ThingTestDriver default constructor..");
}//ThingTestDriver
public static void main(String[] args) {
System.out.println("ThingTestDriver main..");
ListOfThings aList = ListOfThingsUtilities.getListOfThings();
for (int i=0; i<5; i++){
Thing aThing = Thing.getInstance();
aList.add(aThing);
}//for
System.out.println(aList.toString());
System.out.println("..ThingTestDriver main..done.");
}//main
}//ThingTestDriver
Mechanically, ThingTestDriver gave the "non-static context" error method.
getListOfThings() is static, which eliminates the error message.
public class ListOfThingsUtilities {
private ListOfThingsUtilities() {
System.out.println("CollectionOfThingsUtilities..");
}//ListOfThingsUtilities
public static ListOfThings getListOfThings() {
System.out.println("..getListOfThings..");
ListOfThings aList = new ListOfThings();
return aList;
}//ListOfThingsUtilities
public static void main(String[] args) {
System.out.println("ListOfThingsUtilities main..");
}//main
}//ListOfThingsUtilities
ListOfThingsUtilities uses getInstance() from ListOfThings to instantiate
a ListOfThings. Somewhere in the chain of these calls from class to class
and method to method the error method gets circumvented.
public class ListOfThings extends java.util.Vector implements
java.util.List {
public ListOfThings() {
System.out.println("ListOfThings..");
}//ListOfThings
public ListOfThings getInstance() {
System.out.println("..getCollectionOfThings..");
return new ListOfThings();
}//getInstance
public static void main(String[] args) {
System.out.println("ListOfThings main..");
}//main
}//ListOfThings
I *don't* see the underlying reason for ListOfThingsUtilites. In my mind
it's a kludge in response to an error message. On one level I believe I
get the distinction between static methods versus instance methods:
static methods are independant of any instance. I've read that the math
functions are prime examples of this because there's never a "math" object
which operates on Integer objects, for example. another example:
from p273 of Head First Java
public static void main (String[] args){
System.out.println("size of duck is " + size); }
In the above example there are zero to n ducks, so it's ambigious. In my
code, however..um I get a bit lost and have to go back and read it :(
I *suppose* the ambiguity is resolved by calling(java term?) a static
method. That seems *more* than a little pointless since that static
method simply calls a constructor (is a constructor static? I think yes)
which *does* point back to an actual object.
Therefore, it's a kludge since a static method *does* reference a
*particular* object. Therein lies the mystery, for me, since the design
flaw is circumvented with voodoo.
All that happened was that the "error" got lost in the shuffle. It's
arcane and arbitrary and not OO at all :(
clearly there's a fly in the ointment...but where?
thanks,
Thufir Hawat
| |
| Ryan Stewart 2004-07-28, 9:08 pm |
| <thufir.hawat@mail.com> wrote in message
news:Pine.GSO.4.43.0407240242480.14829-100000@earth...
> On Fri, 23 Jul 2004, Ryan Stewart wrote:
> [..]
> I found some material, but not much that was helpful. As I already knew
> the solution I admittedly didn't look that hard. The frustration for me
> is that to make things compile a utility class is needed, but *why*
> escapes me. Until I understand the error message I expect to see it
> again--I fixed the error message by rote.
>
Actually what you have there is a factory class of sorts. It exists solely
for creating instances of another object. It appears unnecessary to me,
though.
> ThingTestDriver checks to see if the the other classes clash:
>
> public class ThingTestDriver {
>
> private ThingTestDriver() {
> System.out.println("ThingTestDriver default constructor..");
> }//ThingTestDriver
>
> public static void main(String[] args) {
> System.out.println("ThingTestDriver main..");
>
> ListOfThings aList = ListOfThingsUtilities.getListOfThings();
>
> for (int i=0; i<5; i++){
> Thing aThing = Thing.getInstance();
> aList.add(aThing);
> }//for
>
> System.out.println(aList.toString());
>
> System.out.println("..ThingTestDriver main..done.");
> }//main
>
> }//ThingTestDriver
>
>
> Mechanically, ThingTestDriver gave the "non-static context" error method.
> getListOfThings() is static, which eliminates the error message.
>
Because "ListOfThingsUtilities" is a class, not an object reference. To
invoke a method without an object reference, the method must be static
because a static method does not "belong to" a specific object.
> public class ListOfThingsUtilities {
>
> private ListOfThingsUtilities() {
> System.out.println("CollectionOfThingsUtilities..");
> }//ListOfThingsUtilities
>
> public static ListOfThings getListOfThings() {
> System.out.println("..getListOfThings..");
> ListOfThings aList = new ListOfThings();
> return aList;
> }//ListOfThingsUtilities
>
> public static void main(String[] args) {
> System.out.println("ListOfThingsUtilities main..");
> }//main
>
> }//ListOfThingsUtilities
>
> ListOfThingsUtilities uses getInstance() from ListOfThings to instantiate
> a ListOfThings. Somewhere in the chain of these calls from class to class
> and method to method the error method gets circumvented.
>
No it doesn't. It uses "new ListOfThings()".
> public class ListOfThings extends java.util.Vector implements
> java.util.List {
>
Vector already implements List. It's redundant to declare it again.
> public ListOfThings() {
> System.out.println("ListOfThings..");
> }//ListOfThings
>
> public ListOfThings getInstance() {
> System.out.println("..getCollectionOfThings..");
> return new ListOfThings();
> }//getInstance
>
For this method to do what you want it to, it should be static. You intend
it to be a factory method, i.e. to create new objects of class ListOfThings
for use. What's the purpose of having a non-static factory method? That
means that you must have an instance of the class in order to create further
instances of the class. Kinda pointless. If the method were static, you
could simply invoke it via "ListOfThings.getInstance()", and it would
produce you a new object.
> public static void main(String[] args) {
> System.out.println("ListOfThings main..");
> }//main
>
> }//ListOfThings
>
> I *don't* see the underlying reason for ListOfThingsUtilites. In my mind
> it's a kludge in response to an error message.
At this level of simplicity, it's not needed. Factory patterns definitely
have their uses, though.
> On one level I believe I
> get the distinction between static methods versus instance methods:
> static methods are independant of any instance. I've read that the math
> functions are prime examples of this because there's never a "math" object
> which operates on Integer objects, for example. another example:
>
> from p273 of Head First Java
> public static void main (String[] args){
> System.out.println("size of duck is " + size); }
>
> In the above example there are zero to n ducks, so it's ambigious. In my
> code, however..um I get a bit lost and have to go back and read it :(
>
Same thing. You can have 0..n ducks ("ListOfThings" objects) as well. So
when calling a method like ListOfThings.add(...), how would it know *which*
ListOfThings to add to? However, ListOfThings.getInstance() is clearly a
sensible method call. It means, "Give me an instance of class ListOfThings,"
and you clearly wouldn't be asking an existing instance for a new instance
(as noted above). Therefore the getInstance method should be static so it
can be invoked independently of an instance.
> I *suppose* the ambiguity is resolved by calling(java term?)
invoking
> a static
> method. That seems *more* than a little pointless since that static
> method simply calls a constructor (is a constructor static? I think yes)
> which *does* point back to an actual object.
>
A constructor has a pointer to the object it is creating and "returns" that
pointer as its result when complete.
> Therefore, it's a kludge since a static method *does* reference a
> *particular* object. Therein lies the mystery, for me, since the design
> flaw is circumvented with voodoo.
>
No, a constructor is not static, nor is it a method. Technically, a
constructor can't actually be explicitly invoked by you, the programmer.
It's invoked via a class instance creation expression. That's the "new
ListOfThings()" expression. This expression can occur in either a static or
non-static context, which can have an impact on exactly how it's evaluated.
> All that happened was that the "error" got lost in the shuffle. It's
> arcane and arbitrary and not OO at all :(
>
It didn't get lost. You've simply eliminated it by randomly shuffling things
around and stumbling upon a working combination, as Grant was saying. It is
neither arcane nor arbitrary, and Java as a whole is the most object
oriented language I've yet seen.
> clearly there's a fly in the ointment...but where?
>
For one thing, what's with all the getInstance methods? Why not just use the
constructor? Like so:
// ***** Start sample code *****
public class ThingTestDriver {
public static void main(String[] args) {
System.out.println("ThingTestDriver main..");
ListOfThings aList = new ListOfThings();
for (int i=0; i<5; i++){
Thing aThing = new Thing();
aList.add(aThing);
}//for
System.out.println(aList.toString());
System.out.println("..ThingTestDriver main..done.");
}//main
}//ThingTestDriver
class ListOfThings extends java.util.Vector {
public ListOfThings() {
System.out.println("ListOfThings..");
}//ListOfThings
}//ListOfThings
class Thing {} // added so code will compile
// ***** End sample code *****
Or if you really, really want to use a factory method:
// ***** Start sample code *****
public class ThingTestDriver {
public static void main(String[] args) {
System.out.println("ThingTestDriver main..");
ListOfThings aList = ListOfThings.getInstance();
for (int i=0; i<5; i++){
Thing aThing = new Thing();
aList.add(aThing);
}//for
System.out.println(aList.toString());
System.out.println("..ThingTestDriver main..done.");
}//main
}//ThingTestDriver
class ListOfThings extends java.util.Vector {
private ListOfThings() {
System.out.println("ListOfThings..");
}//ListOfThings
public static ListOfThings getInstance() {
System.out.println("..getListOfThings..");
return new ListOfThings();
}//getInstance
}//ListOfThings
class Thing {}
// ***** End sample code *****
| |
| thufir.hawat@mail.com 2004-07-28, 9:08 pm |
| On Sat, 24 Jul 2004, Ryan Stewart wrote:
I modified the classes as you suggested, it's cleaner, thanks.
[..]
> Same thing. You can have 0..n ducks ("ListOfThings" objects) as well. So
> when calling a method like ListOfThings.add(...), how would it know *which*
> ListOfThings to add to? However, ListOfThings.getInstance() is clearly a
> sensible method call. It means, "Give me an instance of class ListOfThings,"
> and you clearly wouldn't be asking an existing instance for a new instance
> (as noted above). Therefore the getInstance method should be static so it
> can be invoked independently of an instance.
[..]
> It didn't get lost. You've simply eliminated it by randomly shuffling things
> around and stumbling upon a working combination, as Grant was saying. It is
> neither arcane nor arbitrary, and Java as a whole is the most object
> oriented language I've yet seen.
[..]
I'm still unsure as to where in the shuffle the error was eliminated.
IIRC:
ThingTestDriver.main() is static, invokes
ListOfThingsUtilites.getListOfThings().
ListOfThingsUtilites.getListOfThings() is or should be static and invokes
new ListOfThings.
new ListOfThings returns (?) the created instance.
both Thing.TestDriver.main() and ListOfThingsUtilities.getListOfThings()
are static, both can invoke a new object. I don't see why I was getting
the first error, I'll take a look backwards.
thinking out loud,
Thufir Hawat
|
|
|
|
|