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

Discussion in 'Java' started by John Goche, Nov 30, 2011.

  1. John Goche

    John Goche Guest

    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
     
    John Goche, Nov 30, 2011
    #1
    1. Advertising

  2. John Goche

    Lew Guest

    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
     
    Lew, Nov 30, 2011
    #2
    1. Advertising

  3. On Wed, 30 Nov 2011 11:22:47 -0800 (PST), 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.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Nov 30, 2011
    #3
  4. John Goche

    Lew Guest

    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 astatic member to access an instance member.

    --
    Lew
     
    Lew, Nov 30, 2011
    #4
  5. On Wed, 30 Nov 2011 14:28:56 -0800 (PST), 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?

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Nov 30, 2011
    #5
  6. John Goche

    Lew Guest

    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
     
    Lew, Dec 1, 2011
    #6
  7. On Wed, 30 Nov 2011 19:10:33 -0800 (PST), Lew <>
    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
     
    Gene Wirchenko, Dec 1, 2011
    #7
  8. John Goche

    Roedy Green Guest

    On Wed, 30 Nov 2011 09:22:01 -0800 (PST), John Goche
    <> 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.
     
    Roedy Green, Dec 2, 2011
    #8
  9. John Goche

    Lew Guest

    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
     
    Lew, Dec 2, 2011
    #9
  10. John Goche

    Arne Vajhøj Guest

    Re: state design pattern: question: inner or outer class: which isbetter?

    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
     
    Arne Vajhøj, Dec 3, 2011
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Yamin
    Replies:
    4
    Views:
    16,843
    Yamin
    Oct 24, 2004
  2. Ahan Hsieh
    Replies:
    2
    Views:
    592
    Ahan Hsieh
    Oct 5, 2007
  3. Qi
    Replies:
    4
    Views:
    795
  4. John Gordon
    Replies:
    5
    Views:
    465
    Adam Skutt
    May 9, 2012
  5. Replies:
    2
    Views:
    256
Loading...

Share This Page