Мы знаем, что в Objective-C существуют два основных корневых класса: NSObject и NSProxy. Существуют и другие корни (в основном для частных и устаревших целей), например Object и NSLeafProxy.
Определение нового корня довольно тривиально:
@interface DDRoot <NSObject>
@end
@implementation DDRoot
//implement the methods required by <NSObject>
@end
Мой вопрос: зачем вы хотите определить новый корневой класс? Есть ли какой-то прецедент, где это необходимо?
Насколько я могу судить, не должно быть причин для создания собственного корневого класса, потому что, не выполняя все методы протокола NSObject самостоятельно, вы будете пропускать много функциональности, и собирается делать много звонков в среду выполнения Objective-C, которая должна быть по существу сделана для вас.
Если вам действительно не нужно было выполнять протокол по-другому от стандартного (NSProxy - это особый случай, который вам нужен), вам не нужно создавать собственный корневой класс. Я имею в виду, вам придется писать класс, который не может быть принципиально представлен NSObject и протоколом, реализованным Apple, и в этом случае почему вы даже пишете его в Objective-C?
Что я думаю. Может быть, кто-то может придумать для этого творческое использование.
(Люди, изучающие эту тему, должны посмотреть на Ссылка на класс NSObject, Ссылка на протокол NSObject, "Основные компетенции: класс корневого класса" и раздел "Класс корня" Руководство по основам: Cocoa Документ объектов.)
Есть две основные причины для создания нового корневого класса; проксирования и новой объектной модели.
При проксировании может быть полезно внедрить новый корневой класс, чтобы вы могли в основном обрабатывать все и все поведение класса/объекта по-своему. См. NSProxy.
Время выполнения Objective-C достаточно гибко, что вы можете легко поддерживать новую объектную модель (где легко снижает присущую сложность создания такого зверя в первую очередь). Фактически, многие из поведений, которые считаются неотъемлемыми для среды исполнения - KVC, KVO и т.д., Реализуются как часть самого класса NSObject.
Я знаю, по крайней мере, одну компанию, которая, по крайней мере, примерно 8 лет назад, реализовала свою собственную объектную модель в рамках создания своего механизма финансового анализа LOC объемом 500 тыс. долл.
Ключ, однако, заключается в том, что если вы идете по этому маршруту, вы не пытаетесь взаимодействовать с вашими классами с Foundation/CF/AppKit/UIKit и т.д. Если вам нужно , что, просто подкласс NSObject уже!
Интересно отметить, что NSManagedObject является фактически корневым классом, поскольку он выполняет некоторые довольно серьезные пользовательские вещи, но он является подклассом NSObject, поэтому подклассы NSManagedObject взаимодействуют с остальной частью системы.
Objective-C и Cocoa являются отдельными вещами, и в принципе его можно определить совершенно новые рамки приложения, которые не используют Foundation. Финансовый анализ людей, упомянутых здесь, является практическим примером, и я считаю, что они все еще вокруг.
Другое использование заключается в том, чтобы сделать прокси более минимальным, чем NSProxy, так как Mike Ash делает здесь.
О, а частный NSInvocationBuilder - это корневой класс, предположительно по тем же причинам, что и Mikes proxy. Захват вызовов для последующего использования - это то, что можно было бы воссоздать.
Компании, подобные OmniGroup, определили версию NSObject для использования в качестве своего собственного базового класса для всего.
Это, по сути, подкласс NSObject с некоторыми отладочными материалами. Помимо этого, обычно это ужасная идея для борьбы с каркасом.
Найдите здесь код Omni: https://github.com/omnigroup/OmniGroup