state design pattern: question: inner or outer class: which is better?

[John Goche]

Hello,

I am implementing the state design pattern to manage a set of
sprites in a game. I wonder if anyone could tell me whether it
is better to implement the state classes as inner classes of the
object they are a state of, or as outer classes each being passed
a reference to the sprite object they are being a state for.

Thanks,

John Goche

 

[Lew]

I am implementing the state design pattern to manage a set of
sprites in a game. I wonder if anyone could tell me whether it
is better to implement the state classes as inner classes of the
object they are a state of, or as outer classes each being passed
a reference to the sprite object they are being a state for.

It all depends.

What do you mean by "better"?

What is the use case for the sprite type?

If the sprite state depends on the outer class's state, an inner class can be a convenient shortcut.

As with non-inner nested classes, if the type is needed by any other class and its semantics are not tightly bound to those of the proposed outer class, a standalone class is probably more appropriate.

If the semantics are tightly bound to the proposed outer class, and the sprite state does not depend on the outer class instance's state, then a nested class might be appropriate.

 

[Gene Wirchenko]

[snip]

As with non-inner nested classes, if the type is needed by any other class

and its semantics are not tightly bound to those of the proposed
outer class, a standalone class is probably more appropriate.

If the semantics are tightly bound to the proposed outer class, and the sprite

state does not depend on the outer class instance's state, then a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I do not follow this. Please explain.

nested class might be appropriate.

Sincerely,

Gene Wirchenko

 

[Lew]

Lew wrote:
[snip]

As with non-inner nested classes, if the type is needed by any other class
and its semantics are not tightly bound to those of the proposed
outer class, a standalone class is probably more appropriate.

If the semantics are tightly bound to the proposed outer class, and the sprite

state does not depend on the outer class instance's state, then a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I do not follow this. Please explain.

nested class might be appropriate.

If an instance of the prospective nested class does not use any of the instance state of the prospective outer class, then it should not be an inner class, but it might be a candidate for a nested class.

If it does depend on the state of the outer-class instance, for example if it references an instance variable of the outer-class instance, then it will have to be an inner class. This follows directly from the inability of astatic member to access an instance member.

 

[Gene Wirchenko]

Lew wrote:
[snip]

As with non-inner nested classes, if the type is needed by any other class
and its semantics are not tightly bound to those of the proposed
outer class, a standalone class is probably more appropriate.

If the semantics are tightly bound to the proposed outer class, and the sprite

state does not depend on the outer class instance's state, then a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I do not follow this. Please explain.

nested class might be appropriate.

If an instance of the prospective nested class does not use any of the instance

state of the prospective outer class, then it should not be an inner
class, but it might be a candidate for a nested class.

If it does depend on the state of the outer-class instance, for example if it

references an instance variable of the outer-class instance, then it
will have to be an inner class. This follows directly from the
inability of a static member to access an instance member.

Thank you. It was a terminology issue. I got this from Oracle:
"Nested classes are divided into two categories: static and
non-static. Nested classes that are declared static are simply called
static nested classes. Non-static nested classes are called inner
classes." Are these the definitions that you are using?

Sincerely,

Gene Wirchenko

 

[Lew]

Lew wrote:
[snip]

As with non-inner nested classes, if the type is needed by any other class
and its semantics are not tightly bound to those of the proposed
outer class, a standalone class is probably more appropriate.

If the semantics are tightly bound to the proposed outer class, and the sprite
state does not depend on the outer class instance's state, then a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I do not follow this. Please explain.

nested class might be appropriate.

If an instance of the prospective nested class does not use any of the instance

state of the prospective outer class, then it should not be an inner
class, but it might be a candidate for a nested class.

If it does depend on the state of the outer-class instance, for example if it

references an instance variable of the outer-class instance, then it
will have to be an inner class. This follows directly from the
inability of a static member to access an instance member.

Thank you. It was a terminology issue. I got this from Oracle:
"Nested classes are divided into two categories: static and
non-static. Nested classes that are declared static are simply called
static nested classes. Non-static nested classes are called inner
classes." Are these the definitions that you are using?

Yes. I should have said "static nested class" vs. "inner class"; thanks for the reminder.

I use the definitions in the JLS,
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html>
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.5.2>

but forgot to specify "static" when I said "nested". Thanks for having me clarify and, along the way, refresh the rigor of my terminology.

 

[Gene Wirchenko]

Gene Wirchenko wrote:
[snip]

Yes. I should have said "static nested class" vs. "inner class"; thanks for the reminder.

I use the definitions in the JLS,
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html>
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.5.2>

but forgot to specify "static" when I said "nested". Thanks for having me clarify and, along the way, refresh the rigor of my terminology.

You are welcome.

Sincerely,

Gene Wirchenko

 

[Roedy Green]

Hello,

I am implementing the state design pattern to manage a set of
sprites in a game. I wonder if anyone could tell me whether it
is better to implement the state classes as inner classes of the
object they are a state of, or as outer classes each being passed
a reference to the sprite object they are being a state for.

There are two main reasons to use inner classes:

1. When the inner classes need to intimately access the fields of a
particular mother object they are attached to.

2. When you want scope to partly shield the inner classes from the
outside. They treated somewhat as if they were part of the mother
class.

--
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.

 

[Lew]

John Goche wrote, quoted or indirectly quoted someone who said :

There are two main reasons to use inner classes:

1. When the inner classes need to intimately access the fields of a
particular mother object they are attached to.

2. When you want scope to partly shield the inner classes from the
outside. They treated somewhat as if they were part of the mother
class.

This second point applies to static nested classes as well. Obviously if the needed "fields of a ... mother object" are not static, then only an inner class will do for point #1. If they are static, then the nested class can be as well.

 

[Arne Vajhøj]

I am implementing the state design pattern to manage a set of
sprites in a game. I wonder if anyone could tell me whether it
is better to implement the state classes as inner classes of the
object they are a state of, or as outer classes each being passed
a reference to the sprite object they are being a state for.

If the state classes are actually used outside of the context,
then they should be top level classes.

If not then they really should be inner classes, but there are
a lot of stat pattern implementations out there that uses top
level anyway.

If in doubt, then go for top level.

Arne