Subclassing best practice

  • I have some code which subclasses NSWindow to tack on some data of my
    own:

    @interface MyWindow : NSWindow
    {
    int myStuff;
    MyObject * myMoreStuff;
    }
    - (int) stuff;
    - (MyObject*) moreStuff;
    @end
    @implementation MyWindow
    /* etc */
    @end

    This is super-useful for the project I'm working on since it allows
    me to keep all my data together.
    However, now I have a situation where I need NSPanel to have these
    members as well. So I wrapped up my @interface in a macro:

    #define CreateWindowSubclass(newtype, basetype) \
    @interface newtype : basetype \
    { \
    int stuff; \
    MyObject * moreStuff; \
    } \
    - (int) stuff; \
    - (MyObject*) moreStuff; \
    @end \
    @implementation newtype \
    /* etc */ \
    @end

    CreateWindowSubclass(MyWindow, NSWindow)
    CreateWindowSubclass(MyPanel, NSPanel)

    This works great. However, from a code design perspective, it seems
    sloppy to me. I don't like having to rely on macros.
    In other languages, I could use multiple inheritance, e.g. if this
    were C++ I could do this:

    struct MyWindowExtensions {
    int stuff;
    MyObject * moreStuff;
    };

    class MyWindow : public NSWindow, public MyWindowExtensions {};
    class MyPanel : public NSPanel, public MyWindowExtensions {};

    But ObjC doesn't support multiple inheritance.

    I've run up against this problem with views as well, and I've managed
    to get some mileage out of categories, but there are a lot of
    situations where you just need to add members.

    So what is the best design pattern for something like this? Anything
    nicer than a good old fashioned #define?
  • Am 14.11.2007 um 18:39 schrieb John Stiles:
    > This works great. However, from a code design perspective, it seems
    > sloppy to me. I don't like having to rely on macros.
    > In other languages, I could use multiple inheritance, (...) But ObjC
    > doesn't support multiple inheritance.

      There are a few cases where I used a Macro, too, but in most cases,
    stepping back and looking at the code again helped me find a better
    design that didn't need multiple inheritance:

      E.g. often when I was adding members to a basic class like NSWindow,
    what I really wanted was to have a common base class for my window
    delegates (i.e. the controller), or to add these members to my model
    somewhere. Or sometimes, just splitting the controller into several
    classes helped.

      Sometimes, categories helped, too.

      And also, with ObjC 2.0, one can apparently add properties to
    existing objects somehow. I think this came up on ObjC-Langauge a
    couple days ago.

    Cheers,
    -- M. Uli Kusterer
    "The Witnesses of TeachText are everywhere..."
    http://www.zathras.de
  • On Nov 14, 2007, at 12:39 PM, John Stiles wrote:

    > I have some code which subclasses NSWindow to tack on some data of
    > my own:
    <snip>
    > I've run up against this problem with views as well, and I've
    > managed to get some mileage out of categories, but there are a lot
    > of situations where you just need to add members.
    >
    > So what is the best design pattern for something like this?
    > Anything nicer than a good old fashioned #define?

    There is another trick with categories which access a static (global)
    dictionary with keys which are the objects to be extended and values
    with the additional storage. Nu does this, I believe to make Obj-C
    objects more dynamic.

    It's easy to implement and make a transparent API, but the downside
    is slower (less thread-friendly) access and a clunky, sinking feeling.

    Cheers,
    M
  • On 14-Nov-07, at 11:34 AM, Uli Kusterer wrote:

    > Am 14.11.2007 um 18:39 schrieb John Stiles:
    >> This works great. However, from a code design perspective, it
    >> seems sloppy to me. I don't like having to rely on macros.
    >> In other languages, I could use multiple inheritance, (...) But
    >> ObjC doesn't support multiple inheritance.
    >
    >
    > There are a few cases where I used a Macro, too, but in most
    > cases, stepping back and looking at the code again helped me find a
    > better design that didn't need multiple inheritance:
    >
    > E.g. often when I was adding members to a basic class like
    > NSWindow, what I really wanted was to have a common base class for
    > my window delegates (i.e. the controller), or to add these members
    > to my model somewhere. Or sometimes, just splitting the controller
    > into several classes helped.

    I agree.  I would use either the delegate or the window controller to
    add extra information.  I've only needed to subclass window in order
    to allow an untitled window to become key, by overriding -
    canBecomeKeyWindow.

    dave

    > Sometimes, categories helped, too.
    >
    > And also, with ObjC 2.0, one can apparently add properties to
    > existing objects somehow. I think this came up on ObjC-Langauge a
    > couple days ago.
    >
    > Cheers,
    > -- M. Uli Kusterer
    > "The Witnesses of TeachText are everywhere..."
    > http://www.zathras.de
  • Wow. It looks like a lot more initial setup work than my macro, but
    maybe a better long-term design. I will keep this concept in mind.

    Is it really true that refcounts are implemented in Cocoa the way
    it's described in this article? I wouldn't have guessed :)

    On Nov 14, 2007, at 12:13 PM, Erik Buck wrote:

previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today