Почему NSKeyedUnarchiver существует, когда NSKeyedArchiver наследуется от NSCoder?

Question

Чтобы дать некоторый контекст, я новичок в iOS/Objective-C с веб-дизайном (Ruby/JS/C#). Я понимаю, как работают классы, но я не понимаю, почему первоначальные разработчики написали эти два класса (NSKeyedArchiver и NSKeyedUnarchiver) вместо того, чтобы объединить логику кодирования и декодирования в один класс.

Чтение Apple documentation for the abstract class NSCoder a NSCoderимеет методы как для кодирования, так и для декодирования. Единственное, что я могу придумать, это то, что код был длинным, поэтому первоначальный разработчик разделил его на 2 ... Мне кажется, что разработчику было бы более удобно использовать только один класс, но, возможно, m пропустил что-то нюансированное об этом. Так есть ли исторические причины для этого? Было ли «NSCoder» «удобством» в том, что оно определяет оба API кодирования/декодирования, но предназначено для разделения на кодировщик/декодеры? Я не понимаю, что должен делать NSCoder?

Answer 1

Я считаю, что сохранение функций архивирования и разборки в отдельных классах является результатом применения Single Responsibility Principle, в котором говорится, что класс должен иметь единую, узкую ответственность, которая должна быть полностью инкапсулирована внутри этого класса. Действительно, когда вы создаете экземпляр подкласса NSCoder, вы делаете это либо для архивирования группы объектов, либо для разблокирования данных в группу объектов, но не для обоих.

Эта конструкция не идеальна, потому что теперь у вас есть несколько пар классов (т.е. NSArchiver/NSUnarchiver и NSKeyedArchiver/NSKeyedUnarchiver) связаны communicational cohesion, в то время как дизайн одного класса привело бы к этой зависимости от данных в полной мере инкапсулированные. Это компромисс, по которому дизайнеры библиотеки Cocoa могли пойти в любом случае. Похоже, что они выбрали принцип единой ответственности, ценой введения зависимости формата данных.