Programming Languages – What Do You Call Classes Without Methods?

If iOS followed the naming convention that you propose, the classes you mention would be named:

• UIObjectResponderViewcontroller

• UIObjectResponderViewcontrollerTable

There would also be classes with names like:

• UIObjectResponderView

• UIObjectResponderViewControl

• UIObjectResponderViewControlButton

• UIObjectResponderViewScroll

• UIObjectResponderViewScrollTable

The disadvantages of this naming convention become more and more apparent as this size of the framework grows:

1. Very long class names.

2. Most classes start with the same long prefix, like "UIObjectResponderView..."

3. The sorted order of source files matches the inheritance hierarchy, which isn't nearly as useful as having them groups according to functionality. That is, it's more useful to have XYDetailView and XYDetailViewController end up close to each other than to have XYObjectResponderViewDetail grouped with all the views, and XYObjectResponderViewcontrollerDetail grouped with all the view controllers.

4. Naming classes according to their inheritance chain violates the "Don't Repeat Yourself" (DRY) principle.

5. Makes name completion almost useless -- you have to type most of a very long name before the list of possible completions is useful. In Cocoa Touch, nearly every class is derived from NSObject, and a great many classes are derived from NSResponder, and the number of views is fairly large. So every time you want to type the name of a view, you'd have to type at least "UIObjectResponderView" just to get to the (long) list of view classes.

6. Doesn't work with prefixes. In Objective-C, name prefixes like "NS", "UI", "CF", and "MK" are used to avoid name collisions. UIKit classes all start with "UI", but all those classes are actually derived from NSObject.

7. Doesn't work well with class names made up of multiple words. A view controller is a controller that manages a view; it is not a view. Using your convention, capitalizing both those words would make "UIObjectResponderViewController" appear to be a subclass of "UIObjectResponderView."

The advantages of more conventional naming schemes are pretty much the inverse of the disadvantages listed above:

1. Allows much shorter names, like "UIButton" instead of "UIObjectResponderViewControlButton."

2. Avoids the tediously long common prefixes. Class names are actually readable: "UITextField," "UISlider", "NSManagedObjectContext" and so on.

3. Source files sort into more useful groups.

4. Doesn't violate DRY.

5. You can type just a few characters of a name and get a useful completion list.

6. & 7. Works fine with different prefixes and with multi-word names.

No.

If you create several different classes and inherit them all in a single class you've haven't really improved the situation. You've just one class which is pretending to be a whole bunch of classes. You've made the implementation a lot more complicated and you haven't actually separated the pieces at all. If A inherits from B and C, then A is as complicated as B and C.

Having more than 30 methods does suggest it could benefit from being split up. Maybe there is a clever way to split it up. Sometimes you just can't, and in that case I do recommend have a large class. But often there are clever ways to break the object into several objects.