Какие варианты использования для определения нового корневого класса?

Мы знаем, что в Objective-C существуют два основных корневых класса: NSObject и NSProxy. Существуют и другие корни (в основном для частных и устаревших целей), например Object и NSLeafProxy.

Определение нового корня довольно тривиально:

@interface DDRoot <NSObject>

@end

@implementation DDRoot

//implement the methods required by <NSObject>

@end

Мой вопрос: зачем вы хотите определить новый корневой класс? Есть ли какой-то прецедент, где это необходимо?

Ответы

Ответ 1

Насколько я могу судить, не должно быть причин для создания собственного корневого класса, потому что, не выполняя все методы протокола NSObject самостоятельно, вы будете пропускать много функциональности, и собирается делать много звонков в среду выполнения Objective-C, которая должна быть по существу сделана для вас.

Если вам действительно не нужно было выполнять протокол по-другому от стандартного (NSProxy - это особый случай, который вам нужен), вам не нужно создавать собственный корневой класс. Я имею в виду, вам придется писать класс, который не может быть принципиально представлен NSObject и протоколом, реализованным Apple, и в этом случае почему вы даже пишете его в Objective-C?

Что я думаю. Может быть, кто-то может придумать для этого творческое использование.

(Люди, изучающие эту тему, должны посмотреть на Ссылка на класс NSObject, Ссылка на протокол NSObject, "Основные компетенции: класс корневого класса" и раздел "Класс корня" Руководство по основам: Cocoa Документ объектов.)

Ответ 2

Есть две основные причины для создания нового корневого класса; проксирования и новой объектной модели.

При проксировании может быть полезно внедрить новый корневой класс, чтобы вы могли в основном обрабатывать все и все поведение класса/объекта по-своему. См. NSProxy.

Время выполнения Objective-C достаточно гибко, что вы можете легко поддерживать новую объектную модель (где легко снижает присущую сложность создания такого зверя в первую очередь). Фактически, многие из поведений, которые считаются неотъемлемыми для среды исполнения - KVC, KVO и т.д., Реализуются как часть самого класса NSObject.

Я знаю, по крайней мере, одну компанию, которая, по крайней мере, примерно 8 лет назад, реализовала свою собственную объектную модель в рамках создания своего механизма финансового анализа LOC объемом 500 тыс. долл.

Ключ, однако, заключается в том, что если вы идете по этому маршруту, вы не пытаетесь взаимодействовать с вашими классами с Foundation/CF/AppKit/UIKit и т.д. Если вам нужно , что, просто подкласс NSObject уже!

Интересно отметить, что NSManagedObject является фактически корневым классом, поскольку он выполняет некоторые довольно серьезные пользовательские вещи, но он является подклассом NSObject, поэтому подклассы NSManagedObject взаимодействуют с остальной частью системы.

Ответ 3

Objective-C и Cocoa являются отдельными вещами, и в принципе его можно определить совершенно новые рамки приложения, которые не используют Foundation. Финансовый анализ людей, упомянутых здесь, является практическим примером, и я считаю, что они все еще вокруг.

Другое использование заключается в том, чтобы сделать прокси более минимальным, чем NSProxy, так как Mike Ash делает здесь.

О, а частный NSInvocationBuilder - это корневой класс, предположительно по тем же причинам, что и Mikes proxy. Захват вызовов для последующего использования - это то, что можно было бы воссоздать.

Ответ 4

Компании, подобные OmniGroup, определили версию NSObject для использования в качестве своего собственного базового класса для всего.

Это, по сути, подкласс NSObject с некоторыми отладочными материалами. Помимо этого, обычно это ужасная идея для борьбы с каркасом.

Найдите здесь код Omni: https://github.com/omnigroup/OmniGroup