If iOS followed the naming convention that you propose, the classes you mention would be named:
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:
Very long class names.
Most classes start with the same long prefix, like "UIObjectResponderView..."
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.
Naming classes according to their inheritance chain violates the "Don't Repeat Yourself" (DRY) principle.
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.
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.
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:
Allows much shorter names, like "UIButton" instead of "UIObjectResponderViewControlButton."
Avoids the tediously long common prefixes. Class names are actually readable: "UITextField," "UISlider", "NSManagedObjectContext" and so on.
Source files sort into more useful groups.
Doesn't violate DRY.
You can type just a few characters of a name and get a useful completion list.
& 7. Works fine with different prefixes and with multi-word names.