Внутренний класс Цель C - PullRequest
1 голос
/ 07 сентября 2010

Я портирую проект из C # в Objective-C, и я хотел бы знать, как реализовать внутренний класс в Objective-C (внутреннее значение, видимое только внутри этого проекта).

Например, у меня есть код на C #:

public abstract class AbstractBaseClass : AInterface
{
     // methods go here
}

internal class InternalSubclass : AbstractBaseClass
{
     // methods go here
}

Это код, который я преобразовал до сих пор:

// AbstractBaseClass.h
#import <Foundation/Foundation.h>
#import "AInterface.h"

@interface AbstractBaseClass : NSObject<AInterface>

// methods go here

@end

// AbstractBaseClass.m
#import "AbstractBaseClass.h"

@implementation AbstractBaseClass

-(void) abstractMethod
{
      [NSException raise:@"abstract method" format:@"This method is abstract, and thus cannot be called"];
}

// more methods

@end

Где я должен разместить интерфейсы и реализации InternalSubclasses? Должны ли они быть в отдельном файле с именем InternalClasses.h/m? Или мне просто не нужно иметь заголовок для этих файлов, а просто файл .m для них.

Любая помощь будет оценена!

Ответы [ 4 ]

2 голосов
/ 07 сентября 2010

Обычно я делаю это, объявляя интерфейс и реализацию внутреннего класса в файле .m для базового класса.

Конечно, если классы становятся большими, вам, возможно, придется разделить их, чтобы избежать слишком больших файлов.Если вы пишете фреймворк, существует механизм, позволяющий указать, какие заголовки становятся общедоступными (т. Е. Экспортируются в каталог заголовков фреймворка), в противном случае вам просто нужно обратиться к документации.

1 голос
/ 07 сентября 2010

В Obj-C нет такого же понятия "внутренний".Как говорит Джошуа, лучшее, что вы можете сделать, это просто оставить заголовки для «внутренних» подклассов закрытыми, документируя только интерфейс для базового класса.

Ваш дизайн в порядке, если вы создаете абстрактный базовый класс.Этот дизайн используется Apple для «кластеров классов», когда вы не получаете, скажем, NSString или NSImage, вы получаете что-то еще с тем же интерфейсом.

Другой способ сделать это в Obj-C - использовать формальный протокол:

@protocol AbstractInterface
- (void)method1;
...
@end

Затем вместо обхода AbstractBaseClass * с вы передаете id<AbstractInterface> с.Если ваш базовый класс имеет нулевое состояние и не имеет реализаций по умолчанию, они эквивалентны.

Чтобы ответить на другой вопрос: у каждого класса должны быть свои файлы .h и .m.Это в значительной степени всегда верно независимо от этого конкретного контекста.

0 голосов
/ 07 сентября 2010

Спасибо за все ваши ответы, я решил сделать классы общедоступными, так как в данный момент я буду единственным, кто использует эту библиотеку.Мне было просто интересно, пропустил ли я что-то в документации языка Objective C о внутренних классах, потому что вы можете пометить переменные как @package.

0 голосов
/ 07 сентября 2010

Да, единственный способ создать «внутренние» классы - это скрыть для них заголовки.Но даже в этом случае любой пользователь может использовать эти классы тривиально, если он знает его имя `NSClassFromString '. Я бы сказал, что вы можете подумать о его повторной архитектуре вместо использования стиля проектирования классов, который Obj-C не совсемсделано для.

Не зная больше о том, что вы делаете, я не могу предложить другой дизайн.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...