Object hierarchies in Objective-C

Question

I became acquainted with the Objective-C codebase, which has ~ 50,000 LoC, and I would estimate that 25% or so is duplicate code. Unfortunately, the principles of OO were mostly ignored until now in the code base in favor of copying and pasting logic. Hooray!

I come from the Java background, and a lot of this duplication can be fixed with old-fashioned object-oriented programming. Extracting common logic into a base class in many cases seems like the right solution.

However, before I begin to create a group of base classes and share a common logic between derived classes, I thought that I should stop and see if there are any other options available to me. After watching Ken Kocienda’s WWDC session “Writing Simple Code for Change” since 2011, he advises me to keep object hierarchies as small as possible. He does not offer any hard statistics on why he has such an opinion, so I wonder if I'm missing something.

I am not an Objective-C expert in any part of the imagination, so I wonder if there are any recommendations when choosing a hierarchy of objects. Basically, I would like to get an opinion about when you decide to stop creating base classes and start using composition instead of inheritance as a way to share code between classes.

Also, in terms of performance at runtime, is there something that can affect the creation of a hierarchy of objects?

Answer 1

I recalled some thoughts about in iOS from other backgrounds , including Java. Some things have changed due to ARC. In particular, memory management is no longer front-line and central. However, everything you did to simplify memory management (use accessors, use accessors, use accessors) is still equally true in ARC.

@Radu is perfectly correct that you should often keep class hierarchies fairly simple and shallow (as you read). Composition is often much better for Cocoa than extensive subclasses (this is probably true in Java, but it is common practice in ObjC). ObjC also has no concept of an abstract method or class, which makes some subclasses a bit uncomfortable. Instead of extracting common logic into base classes (especially abstract base classes), it is often better to extract them into a separate strategy object.

See the UITableView and its use of delegates and data sources. Look at things like NSAttributedString , which is HAS-A NSString , not IS-A. This is common and often keeps things cleaner. As with all large object hierarchies, always keep the LSP . I see that the ObjC design goes sideways when someone forgets that a square is not a rectangle . Again, this applies to all languages, but it is worth remembering during development.

Immutable objects (values) are a real victory whenever you can use them.

The other part that you quickly discover is that there are very few “protective decorations” such as “final” or “protected” (there is @protected , but this is not really useful in practice and is rarely used). People from the Java and C ++ backgrounds tend to worry about compilers complying with various access rules. ObjC has no protection against most protected compilers (you can always send any message you want for any object at runtime). You just use consistent naming conventions and don’t look at private methods. Programming discipline applied. In practice, this works very well in the vast majority of cases.

However, ObjC has many warnings, and you absolutely must eliminate all warnings. Most ObjC warnings are actually errors.

I deviated a little from the specific question about object hierarchies, but hopefully this is helpful.

Answer 2

One of the serious problems with deep hierarchies in Objective-C is that Xcode does not help you understand / manage them at all. The other is that almost anything in Objective-C gets about twice as complicated as its Java equivalent, so you need to work harder to simplify the simple work.

But I find the composition in Objective-C uncomfortable (although I can’t say exactly why), therefore there is no “perfect” answer.

I noticed that small routines are much less common in Objective-C compared to Java, and it is much more likely that the code is duplicated between mostly identical view controllers, etc. I think that most of this is just development tools and relative awkwardness when creating new classes.

PS: I had to rework an application containing approximately 55 thousand lines, as close as we could count. As you found, there was probably about 25% duplication, but there was also about 25% completely dead code. (Fortunately, this app has been largely abandoned since.)