Why does NSKeyedUnarchiver exist when NSKeyedArchiver inherits from NSCoder?

Question

To give some context, I'm new to iOS/Objective-C with a web dev (Ruby/JS/C#) background. I understand how the classes work, but I don't understand why the original implementors wrote these two classes (NSKeyedArchiver and NSKeyedUnarchiver) instead of consolidating both encoding and decoding logic into a single class.

Reading the Apple documentation for the abstract class NSCoder a NSCoder has methods to both encode and decode. The only thing I can think of is that the code was long so the original implementer split it into 2... It seems to me that it'd be more convenient to the developer that only a single class is used, but maybe I'm missing something nuanced about this. So are there any historical reasons for this? Was NSCoder a "convenience" in that it defines both the encoding/decoding APIs, but meant to be separated into encoder/decoders? Am I misunderstanding what a NSCoder is supposed to do?

Answer 1

I think that keeping archiving and unarchiving functionality in separate classes is the result of applying the Single Responsibility Principle, which says that a class has to have a single, narrow, responsibility, which should be fully encapsulated inside that class. Indeed, when you create an instance of NSCoder's subclass, you do that either to archive a group of objects, or to unarchive data into a group of objects, but not both.

This design is not ideal, because now you have several pairs of classes (i.e. NSArchiver/NSUnarchiver and NSKeyedArchiver/NSKeyedUnarchiver) linked by communicational cohesion, while a single-class design would have lead to this data dependency being fully encapsulated. This is a tradeoff on which the designers of the Cocoa library could have gone either way. It appears that they picked single responsibility principle, at the price of introducing a data format dependency.