How to split large class files?

  • I have a controller class which has become quite large. It has many instance variables which are all related to the view it connects to, and which are manipulated inside the class. Is there a clear way to split such a file into two (or more) components? I considered making a category, but that's not quite good because it cannot have (new) instance variables in it. Moreover, I cannot have the instance var declarations in the original file and the code in the category; that will generate many warnings.  Any suggestions?  Thanks in advance, Arthur C.
  • On Nov 4, 2007, at 11:37 AM, Arthur C. wrote:
    > I have a controller class which has become quite large. It has many
    > instance variables which are all related to the view it connects to,
    > and which are manipulated inside the class. Is there a clear way to
    > split such a file into two (or more) components? I considered making
    > a category, but that's not quite good because it cannot have (new)
    > instance variables in it. Moreover, I cannot have the instance var
    > declarations in the original file and the code in the category; that
    > will generate many warnings.  Any suggestions?  Thanks in advance,
    > Arthur C.

    You can certainly have the iVar declarations in the main @interface
    declaration and references to the ivars in categories without
    warnings.  Works fine.  If you are seeing warnings, then something
    else is hosed.

    I'd suggest having a close look at your controller to see if it can't
    be broken up into multiple classes.  Huge source files are usually an
    indication that something needs to be refactored.  Usually.
    Controller classes are the one class that can sometimes grow quite
    large.

    b.bum
  • On Nov 4, 2007, at 12:04 PM, Bill Bumgarner wrote:

    >> I have a controller class which has become quite large. It has many
    >> instance variables which are all related to the view it connects
    >> to, and which are manipulated inside the class. Is there a clear
    >> way to split such a file into two (or more) components? I
    >> considered making a category, but that's not quite good because it
    >> cannot have (new) instance variables in it. Moreover, I cannot have
    >> the instance var declarations in the original file and the code in
    >> the category; that will generate many warnings.  Any suggestions?
    >> Thanks in advance, Arthur C.
    >
    > You can certainly have the iVar declarations in the main @interface
    > declaration and references to the ivars in categories without
    > warnings.  Works fine.  If you are seeing warnings, then something
    > else is hosed.
    >
    > I'd suggest having a close look at your controller to see if it
    > can't be broken up into multiple classes.  Huge source files are
    > usually an indication that something needs to be refactored.
    > Usually.  Controller classes are the one class that can sometimes
    > grow quite large.

    I've wondered at what point does it cross the line from being just
    "big" to "dudeā€¦ refactor your code" big.

    The largest controller I have in any project is about 5,000 lines
    including comments and empty lines etc. Feels too big to me, but
    breaking it up into multiple classes just lead to having too many
    interdependent classes, so I just busted it up into separate files and
    categories to group things logically for my own benefit. Doesn't
    change the code usage at all. It's a happy medium for now.

    --
    Seth Willits
  • On Nov 5, 2007, at 8:37 PM, Seth Willits wrote:
    > The largest controller I have in any project is about 5,000 lines
    > including comments and empty lines etc. Feels too big to me, but
    > breaking it up into multiple classes just lead to having too many
    > interdependent classes, so I just busted it up into separate files
    > and categories to group things logically for my own benefit. Doesn't
    > change the code usage at all. It's a happy medium for now.

    Another way to refactor, besides "horizontally" into categories and
    cooperating classes, is "vertically" into subclasses.  Maybe some of
    your ivars and methods can be grouped into a top-level class, others
    into a subclass, others into a subclass of *that*, etc.  Even if
    you'll never create other subclasses of the intermediate classes, it
    might help with clarity and debugging just to break up the class's
    logic this way.  For example, you can write unit tests specific to an
    intermediate class that don't have to worry about possible
    complications added by the code in subclasses.

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