Returning a reference to an object

Thread view:

PGR - 02 Jan 2006 21:59 GMT

Hi,

I've created a class to implement a state machine, so it's got a State
attribute. It has algo got a private java.util.Stack attribute.

In order to work, State classes need to access the stack to push and pop
data, etc.
To access it from State, I have wrote a method called getStack() which
returns a reference to the stack, but I think this is not recommended
beacause all objects sharing the reference can modify it, and led to errors
difficult to debug, etc. Returning a stack's clone is not valid solution,
as I have to make changes on the real one.

So my question is, is there a cleaner way to do this?

Thank you very much

Signature

PGR

Reply to this Message

Stefan Ram - 02 Jan 2006 23:05 GMT

>I've created a class to implement a state machine, so it's got a State
>attribute. It has algo got a private java.util.Stack attribute.
>In order to work, State classes need to access the stack to push and pop
>data, etc. ~~~~~~~

You should use objects, not classes, to model your world.

>To access it from State, I have wrote a method called getStack() which
>returns a reference to the stack, but I think this is not recommended
>beacause all objects sharing the reference can modify it, and led to errors
>difficult to debug, etc. Returning a stack's clone is not valid solution,
>as I have to make changes on the real one.

Either the callee should be allowed to modify the collection
or not. If he should be allowed to modify it, why not return
the reference? Otherwise, possibly an operation like the
following might help?

http://download.java.net/jdk6/docs/api/java/util/Collections.html#unmodifiableCo
llection(java.util.Collection)

Reply to this Message

Chris Smith - 03 Jan 2006 23:58 GMT

> You should use objects, not classes, to model your world.

This is probably irrelevant to the OP, but I'm trying to figure out what
you mean by this. In a class-based language like Java, you define how
objects model the world by writing classes. It's not as if there's a
choice somewhere between modeling with objects or with classes. You
must use both, if the language is class-based.

Signature

www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Reply to this Message

Stefan Ram - 04 Jan 2006 00:08 GMT

>>You should use objects, not classes, to model your world.
>This is probably irrelevant to the OP, but I'm trying to figure
>out what you mean by this. In a class-based language like Java,
>you define how objects model the world by writing classes.

Actually, one writes /class declarations/ - not classes.

Otherwise, I agree. The classes are means to build objects at
run times. The actual players in the OO-universe, to me, are
objects.

I was replying to »[s]tate classes need to access the stack to
push and pop data« To me, at run time, the /objects/ do access
a stack or push data -- not their classes.

>It's not as if there's a choice somewhere between modeling with
>objects or with classes. You must use both, if the language is
>class-based.

I believe that I am modelling the run-time world predominantly
by objects. Class declarations and classes are predominantly
source-code level means to build these objects.

Reply to this Message

Roedy Green - 03 Jan 2006 03:34 GMT

>So my question is, is there a cleaner way to do this?

don't all the states have to share the same stack? If so, you could
make it static. You have only one thread right?

I have been doing a series of state machines using the enum feature
where each state is represented by an Enum constant. You could then
make the stack either a static of the enum. You don't want to make it
an instance of the enum or else every state gets a private one.

Logically the stack belongs in the same instance as the enum
reference, but I know of know easy way to put it there and let the
enum code see it.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Reply to this Message

PGR - 03 Jan 2006 04:00 GMT

> don't all the states have to share the same stack? If so, you could
> make it static.

I thought making it static, but there is a problem: not only the states
share it, but also the finite machine does.
The stack is used to store numbers, state's methods push and pop data in it,
and some machine's methods also do in order to avoid repeating code to
implement actions which are common to all states (for example cleaning the
stack, adding all numbers and getting a result, etc)

> You have only one thread right?

I haven't made anything concerned with threads, but there's a Swing GUI in
the project to handle the state machine and I think Swing deal's with
threads.

Thanks!

Signature

PGR

Reply to this Message

Rodrigo Zechin - 03 Jan 2006 11:42 GMT

The java.util.Stack is thread-safe and uses sinchronization on its own
instance. If u need to perform atomic operations on it, just do:

synchronized(stack) {
.. lots of things that deal with the stack ..
}

Zechin

Reply to this Message

Returning a reference to an object

Free Magazines