Do you nest classes inside classes?

Discussion in 'Ruby' started by Mike Stephens, May 25, 2009.

  1. Object Orientation is conceptually about a sea of objects interacting
    with each other. They are all however in one sea.

    Earlier in Computer Science, we had stepwise refinement, which was a
    tree-like view of application compartmentalisation. High level functions
    would be split into lower level consituents and so on.

    I was thinking to model that in Ruby you would like to be able to
    contain classes within other classes in a similar tree like format, and
    what a shame that Ruby doesn't let you do that.

    But of course it does. However people don't talk about it. Hal Fulton in
    his book The Ruby Way asks people to let him know if they can think of a
    good use for this feature.

    Do you ever use this? Can you see a reason why it doesn't seem to be
    favoured?
    --
    Posted via http://www.ruby-forum.com/.
    Mike Stephens, May 25, 2009
    #1
    1. Advertising

  2. Mike Stephens

    James Coglan Guest

    [Note: parts of this message were removed to make it a legal post.]

    2009/5/25 Mike Stephens <>

    > Object Orientation is conceptually about a sea of objects interacting
    > with each other. They are all however in one sea.
    >
    > Earlier in Computer Science, we had stepwise refinement, which was a
    > tree-like view of application compartmentalisation. High level functions
    > would be split into lower level consituents and so on.
    >
    > I was thinking to model that in Ruby you would like to be able to
    > contain classes within other classes in a similar tree like format, and
    > what a shame that Ruby doesn't let you do that.
    >
    > But of course it does. However people don't talk about it. Hal Fulton in
    > his book The Ruby Way asks people to let him know if they can think of a
    > good use for this feature.
    >
    > Do you ever use this? Can you see a reason why it doesn't seem to be
    > favoured?




    I use classes as namespaces quite a lot. Typically, I will nest a class
    inside another if the inner class is used directly only by the outer class
    and not by other parts of the system. It's not a hard-and-fast rule but I
    find this to be a useful organisational feature.
    James Coglan, May 25, 2009
    #2
    1. Advertising

  3. Mike Stephens <> writes:

    > Object Orientation is conceptually about a sea of objects interacting
    > with each other. They are all however in one sea.
    >
    > Earlier in Computer Science, we had stepwise refinement, which was a
    > tree-like view of application compartmentalisation. High level functions
    > would be split into lower level consituents and so on.
    >
    > I was thinking to model that in Ruby you would like to be able to
    > contain classes within other classes in a similar tree like format, and
    > what a shame that Ruby doesn't let you do that.
    >
    > But of course it does. However people don't talk about it. Hal Fulton in
    > his book The Ruby Way asks people to let him know if they can think of a
    > good use for this feature.
    >
    > Do you ever use this? Can you see a reason why it doesn't seem to be
    > favoured?


    The problem here is the collusion between two notions: that of
    namespace and that of class.

    There's no reason, a-priori, why both notion should match. (In some
    languages such as Common Lisp, they don't).

    In Ruby, you could use a module as a pure namespace, and avoid putting
    classes inside classes: when you have "private" classes you want to
    keep in a specific namespace, it would be better IMO to put them in a
    module rather in a class.


    A good example, would be any abstract data type that needs some
    internal structure, eg. a Tree with Node. If the nodes are not part
    of the public API of the tree, there's no reason to make them public,
    so it would be good to hide them in some namespace specific to the
    tree. But as I said above, I think it would be better to use a module
    to package them.

    --
    __Pascal Bourguignon__
    Pascal J. Bourguignon, May 25, 2009
    #3
  4. Mike Stephens

    Andy F Guest

    Hi Mike,=0A=0ARuby and list noob here. Generally I think using nested class=
    es for real helper classes that=A0can conceptually only be for use with the=
    parent class is a useful way of avoiding namespace clutter. I'd be careful=
    of building large hierarchies, especially deep ones tho. I feel if your go=
    al is nice decoupling then you want small distinct usable classes/objects. =
    Also I guess if you're more of an agile developer, the hierarchy could disc=
    ourage/slow down some refactoring.=0A=0A2 cents=0A=0AA.
    Andy F, May 25, 2009
    #4
  5. Mike Stephens

    trans Guest

    On May 25, 7:24=A0am, Andy F <> wrote:

    > Generally I think using nested classes for real helper classes that can c=

    onceptually only be for use with the parent class is a useful way of avoidi=
    ng namespace clutter.

    +1

    This is the only really good reason I've found for doing so.

    On very rare occasion, when I had only one term in mind for both a
    namespace and a base class, this has seemed useful:

    class BaseClass

    class SubClass < self
    end

    end

    The fact hat the namespace is a class rather than a module is
    inconsequential. In fact, I remain of the opinion that Ruby would be
    better if Class and Module were not distinct.

    T.
    trans, May 25, 2009
    #5
  6. On Mon, May 25, 2009 at 8:53 AM, trans <> wrote:
    >
    >
    > On May 25, 7:24=A0am, Andy F <> wrote:
    >
    >> Generally I think using nested classes for real helper classes that can =

    conceptually only be for use with the parent class is a useful way of avoid=
    ing namespace clutter.


    > This is the only really good reason I've found for doing so.


    I can't agree with that, the value of namespaces is orthogonal to
    ideas like 'private' classes, in fact, I think it's more valuable when
    the names are intended to be used outside of the implementation of a
    class, it helps whenever two things end up competing for a name.

    For example in my new icalendar gem, I use nested name spacing so that
    I can have an Event class, and a using application can have it's own
    Event class(es), maybe one might be a database model.

    I've seen, and been involved with too many languages which suffered
    from the lack of Namespaces, sometimes adding them in later versions
    of the language, not to appreciate the value.

    It really isn't an issue of containing a class within a class, it's an
    issue of containing names within name spaces.

    And I do other things like putting a module which I've used to
    refactor a large class into separate files inside the namespace of the
    (main or only) class which includes it.
    http://github.com/rubyredrick/ri_cal/tree/master

    --=20
    Rick DeNatale

    Blog: http://talklikeaduck.denhaven2.com/
    Twitter: http://twitter.com/RickDeNatale
    WWR: http://www.workingwithrails.com/person/9021-rick-denatale
    LinkedIn: http://www.linkedin.com/in/rickdenatale
    Rick DeNatale, May 25, 2009
    #6
  7. Mike Stephens

    trans Guest

    On May 25, 9:47=A0am, Rick DeNatale <> wrote:
    > On Mon, May 25, 2009 at 8:53 AM, trans <> wrote:
    >
    > > On May 25, 7:24=A0am, Andy F <> wrote:

    >
    > >> Generally I think using nested classes for real helper classes that ca=

    n conceptually only be for use with the parent class is a useful way of avo=
    iding namespace clutter.
    > > This is the only really good reason I've found for doing so.

    >
    > I can't agree with that, the value of namespaces is orthogonal to
    > ideas like 'private' classes, in fact, I think it's more valuable when
    > the names are intended to be used outside of the implementation of a
    > class, it helps whenever two things end up competing for a name.
    >
    > For example in my new icalendar gem, I use nested name spacing so that
    > I can have an Event class, and a using application can have it's own
    > Event class(es), maybe one might be a database model.


    I'm not seeing how you disagree. The example you give is seems like a
    fair example of the reason stated. I take it you have an ICalendar
    class as the top namespace? Then Event is being used by it, even if in
    a round about way --and even if the class could be used independently,
    it was designed for use in this context.

    > I've seen, and been involved with too many languages which suffered
    > from the lack of Namespaces, sometimes adding them in later versions
    > of the language, not to appreciate the value.
    >
    > It really isn't an issue of containing a class within a class, it's an
    > issue of containing names within name spaces.


    Sure, but the question translates to Ruby as a question of practice,
    i.e. typically one should use modules for name spaces, and hence the
    question arises, when is using a class as a name space a better idea?

    > And I do other things like putting a module which I've used to
    > refactor a large class into separate files inside the namespace of the
    > (main or only) class which includes it.http://github.com/rubyredrick/ri_c=

    al/tree/master

    That's cool. Your making class components. Still falls well into the
    stated reason --the class is making use of the modules.

    T.
    trans, May 26, 2009
    #7
  8. Mike Stephens

    Simon Chiang Guest

    I sometimes use nested classes to avoid namespace clutter. The only
    downsides I found are related to inheritance, in particular when you
    split out classes into different files.

    [a.rb]
    require 'a/b'
    class A < SuperClass
    end

    [a/b.rb]
    class A < SuperClass
    class B
    end
    end

    In both files you have to have the correct superclass (which can be
    hard during refactoring). There are different ways to construct this,
    however:

    [a.rb]
    class A < SuperClass
    require 'a/b'
    end

    [a/b.rb]
    class A::B
    end

    The downside of this is that 'a/b.rb' can't be required on it's own.
    Simon Chiang, May 26, 2009
    #8
  9. On Tue, May 26, 2009 at 10:38 AM, Simon Chiang <> w=
    rote:
    > I sometimes use nested classes to avoid namespace clutter. =A0The only
    > downsides I found are related to inheritance, in particular when you
    > split out classes into different files.
    >
    > =A0[a.rb]
    > =A0require 'a/b'
    > =A0class A < SuperClass
    > =A0end
    >
    > =A0[a/b.rb]
    > =A0class A < SuperClass
    > =A0 =A0class B
    > =A0 =A0end
    > =A0end
    >
    > In both files you have to have the correct superclass (which can be
    > hard during refactoring). =A0There are different ways to construct this,
    > however:
    >
    > =A0[a.rb]
    > =A0class A < SuperClass
    > =A0 =A0require 'a/b'
    > =A0end
    >
    > =A0[a/b.rb]
    > =A0class A::B
    > =A0end
    >
    > The downside of this is that 'a/b.rb' can't be required on it's own.



    Sounds like a job for Ruby's not-well-enough-known Module#autoload

    http://talklikeaduck.denhaven2.com/2009/04/06/all-that-you-might-require


    --=20
    Rick DeNatale

    Blog: http://talklikeaduck.denhaven2.com/
    Twitter: http://twitter.com/RickDeNatale
    WWR: http://www.workingwithrails.com/person/9021-rick-denatale
    LinkedIn: http://www.linkedin.com/in/rickdenatale
    Rick DeNatale, May 26, 2009
    #9
  10. Mike Stephens

    Eric Hodel Guest

    On May 25, 2009, at 03:40, Mike Stephens wrote:

    > Do you ever use this? Can you see a reason why it doesn't seem to be
    > favoured?


    I use it all the time, and it is highly favored. It's common in the
    standard library. Resolv, RDoc, RubyGems, Net::HTTP, ...
    Eric Hodel, May 26, 2009
    #10
  11. 2009/5/26 Simon Chiang <>:
    > I sometimes use nested classes to avoid namespace clutter. =A0The only
    > downsides I found are related to inheritance, in particular when you
    > split out classes into different files.
    >
    > =A0[a.rb]
    > =A0require 'a/b'
    > =A0class A < SuperClass
    > =A0end
    >
    > =A0[a/b.rb]
    > =A0class A < SuperClass
    > =A0 =A0class B
    > =A0 =A0end
    > =A0end
    >
    > In both files you have to have the correct superclass (which can be
    > hard during refactoring). =A0There are different ways to construct this,
    > however:
    >
    > =A0[a.rb]
    > =A0class A < SuperClass
    > =A0 =A0require 'a/b'
    > =A0end
    >
    > =A0[a/b.rb]
    > =A0class A::B
    > =A0end
    >
    > The downside of this is that 'a/b.rb' can't be required on it's own.


    IMHO this is not a problem of inheritance but of clear priority: class
    A should be defined in one primary file. All other files that
    *modify* it (i.e. by adding method or whatnot) should require that
    primary file and reopen the class to do whatever they need.

    So, basically the layout should look like this:

    [a.rb]
    class A < SuperClass
    def method_of_A_which_does_not_use_B
    end
    end

    [a/b.rb]
    require 'a'

    class A
    class B
    end

    def method_of_A_which_uses_B
    end
    end

    Actually, if you use A only for namespace handling then a module would
    probably a better thing to have here. Other than that, if A's
    implementation needs A::B to work, then splitting both out into two
    files does not make much sense.

    Kind regards

    robert


    --=20
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, May 27, 2009
    #11
    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. Chad
    Replies:
    1
    Views:
    428
    Natty Gur
    Dec 18, 2003
  2. krzysiek
    Replies:
    0
    Views:
    1,573
    krzysiek
    Oct 18, 2004
  3. =?Utf-8?B?UmFlZCBTYXdhbGhh?=

    Nest Web Projects

    =?Utf-8?B?UmFlZCBTYXdhbGhh?=, Jul 19, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    402
    Brock Allen
    Jul 19, 2005
  4. Mike
    Replies:
    5
    Views:
    5,005
  5. Fuzzie Dice
    Replies:
    0
    Views:
    337
    Fuzzie Dice
    May 21, 2007
Loading...

Share This Page