Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10367 > unrolled thread

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

Back to article view | Back to comp.lang.java.programmer

Contents

  state design pattern: question: inner or outer class: which is better? John Goche <johngoche99@googlemail.com> - 2011-11-30 09:22 -0800
    Re: state design pattern: question: inner or outer class: which is better? Lew <lewbloch@gmail.com> - 2011-11-30 11:22 -0800
      Re: state design pattern: question: inner or outer class: which is better? Gene Wirchenko <genew@ocis.net> - 2011-11-30 14:04 -0800
        Re: state design pattern: question: inner or outer class: which is better? Lew <lewbloch@gmail.com> - 2011-11-30 14:28 -0800
          Re: state design pattern: question: inner or outer class: which is better? Gene Wirchenko <genew@ocis.net> - 2011-11-30 15:03 -0800
            Re: state design pattern: question: inner or outer class: which is better? Lew <lewbloch@gmail.com> - 2011-11-30 19:10 -0800
              Re: state design pattern: question: inner or outer class: which is better? Gene Wirchenko <genew@ocis.net> - 2011-11-30 19:23 -0800
    Re: state design pattern: question: inner or outer class: which is better? Roedy Green <see_website@mindprod.com.invalid> - 2011-12-02 01:47 -0800
      Re: state design pattern: question: inner or outer class: which is better? Lew <lewbloch@gmail.com> - 2011-12-02 07:27 -0800
    Re: state design pattern: question: inner or outer class: which is better? Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 21:32 -0500

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

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

[toc] | [next] | [standalone]

#10370

John Goche wrote:
> 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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10382

On Wed, 30 Nov 2011 11:22:47 -0800 (PST), Lew <lewbloch@gmail.com>
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.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#10384

Gene Wirchenko wrote:
> 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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10386

On Wed, 30 Nov 2011 14:28:56 -0800 (PST), Lew <lewbloch@gmail.com>
wrote:

>Gene Wirchenko wrote:
>> 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

[toc] | [prev] | [next] | [standalone]

#10395

Gene Wirchenko wrote:
> Lew wrote:
>> Gene Wirchenko wrote:
>>> 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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10397

On Wed, 30 Nov 2011 19:10:33 -0800 (PST), Lew <lewbloch@gmail.com>
wrote:

>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

[toc] | [prev] | [next] | [standalone]

#10415

On Wed, 30 Nov 2011 09:22:01 -0800 (PST), John Goche
<johngoche99@googlemail.com> wrote, quoted or indirectly quoted
someone who said :

>
>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.
 

[toc] | [prev] | [next] | [standalone]

#10427

 Roedy Green wrote:
> John Goche wrote, quoted or indirectly quoted someone who said :
>> 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.

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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10453

On 11/30/2011 12:22 PM, John Goche wrote:
> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web