Я думал об этом же и думаю, что у меня есть для вас ответ.

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

Продолжайте читать, если хотите узнать подробности того, как я пришел к своему выводу, или прокрутите вниз до раздела tl; dr.

Как вы сказали, было бы (внешне) менее громоздко получить доступ к синглтону, чтобы класс управлял синглтоном за вас. По сути, это можно сделать, заменив фабричный метод синглтона на метод инициализатора. Глядя на Документация Apple по этому поводу, вы можете увидеть, где они показывают "общий" метод, который действует как фабрика для создания синглтона по запросу.

static MyGizmoClass *sharedGizmoManager = nil;

+ (MyGizmoClass*)sharedManager
{
    if (sharedGizmoManager == nil) {
        sharedGizmoManager = [[super allocWithZone:NULL] init];
    }
    return sharedGizmoManager;
}

Вместо этого вы можете заменить метод инициализатором void следующим образом:

+ (void)initializeMyGizmo
{
    if (sharedGizmoManager == nil) {
        sharedGizmoManager = [[super allocWithZone:NULL] init];
    }
    // whatever else needs to be done to the singleton to initialize it
}

а затем ТОЛЬКО использовать методы класса и разрешить MyGizmoClass управлять обновлениями синглтона, например [MyGizmoClass setGizmoName:@"Gadget"].

ПРИМЕЧАНИЕ. В этом сценарии кто-то, просматривающий файл .h, может запутаться в поисках свойств, и в этом случае он может прийти к выводу, что им следует создать экземпляр сам объект или иметь доступ к синглтону в той или иной форме. Итак, если вы выбрали путь инкапсуляции доступа к синглтону, было бы неразумно использовать общедоступные переменные.

К этому моменту:

Если вы ограничиваете доступ только через сам класс, вы теряете все геттеры и сеттеры или другие бесплатные вещи, которые идут вместе со свойствами. Это означает, что если бы MyGizmoClass как часть своей модели NSString *gizmoName, вы были бы вынуждены создавать собственные геттеры и сеттеры для этого «свойства» и сохранять его либо как ivar, либо как свойство в расширении интерфейса в файле .m (т. Е. Частном ) одноэлементного класса или в качестве смежной статической переменной.

Таким образом, возникает вопрос (и это то, о чем я задумался в первую очередь), должны ли мы вообще включать строку static MyGizmoClass *sharedGizmoManager = nil; или можем вообще исключить расширение внутреннего интерфейса и заменить любые возможные ivars или свойства, к которым мы хотим ограничить доступ с static реализациями в реализации?

Я уже ответил на это ...

Это зависит от того, что вам нужно с этим делать.

tl;dr

Первый сценарий

Если вам когда-либо (даже при малейшей вероятности) потребуется создать подкласс вашего TextureManager или вы могли бы создать несколько его экземпляров (что делает его больше не синглтоном), было бы лучше придерживаться обычного соглашения Apple для синглтона.

Это включает в себя несколько «синглтонов», в которых у вас может быть несколько TextureManager, предварительно сконфигурированных с разными настройками.

В этом случае вы можете использовать свойства по мере необходимости (публично или приватно), а также ivars. Вы также можете использовать сочетание ivars и static, но вам все равно всегда нужно иметь статический экземпляр вашего TextureManager внутри реализации TextureManager.

Второй сценарий

Если вам ТОЛЬКО когда-либо понадобится ОДИН экземпляр TextureManager, и он будет работать полностью автономно без перемешивания дальше по строке, вы можете полностью удалить статический экземпляр вашего класса в реализации в файле .m и замените ivars и свойства статическими переменными в этой реализации.

Это может быть полезно, если вы сохраняете свойства или настройки в CoreData и нуждаетесь в них только для настройки.

Просто помните: в этом случае вам нужно будет создать все геттеры и сеттеры для статических переменных, и вы сможете получить к ним доступ только с помощью методов класса (но в этом вся суть).

Другие интересные вещи

Этот ответ предлагает интересное решение вопроса о том, когда и как вызывать метод «инициализатора» или создавать синглтон. Это можно использовать в каждом сценарии либо для инициализации синглтона в первом сценарии, либо для предварительной загрузки значений по умолчанию в статику уровня класса во втором сценарии.

Если вы хотите использовать статический синглтон в реализации, вы можете посмотреть в этой статье, чтобы дать вам лучшее представление об истинной« глобальной области действия »вашего синглтона.

Да, вы определенно можете создать класс текстуры без синглтона.

Синглтоны, вероятно, не следует создавать и использовать как объект.

Синглтоны можно использовать для многих важных вещей.
Я, конечно, не знаю всего, для чего они могут быть использованы, но я расскажу вам, для чего я их использовал в прошлом.

Я обычно использую синглтоны для навигации по уровням в игре со многими уровнями (например, Angry Birds).
Под навигацией по уровням я имею в виду ... когда игрок завершает определенный уровень в игре, я просто вызываю метод класса для синглтона и передайте номер уровня, тогда метод класса singleton определяет, какой уровень следующий (если пользователь нажимает кнопку «следующий уровень»).

Я могу помочь вам лучше понять класс Singleton и его применимость.

Шаблон: синглтон

Намерение: обеспечить, чтобы класс мог иметь только один экземпляр, а также сделать этот экземпляр доступным для любого другого объекта.

Мотивация: иногда нам нужно убедиться, что в нашей проблемной области существует только один объект определенного типа. Пример: ученик носит с собой только один рюкзак, который он может заполнить книгами. Не хотелось бы относить его к второстепенному рюкзаку, с еще большим количеством книг.

Использовать, когда:

• Требуется только один экземпляр класса, и этот экземпляр должен быть доступен из разных объектов в вашем коде.
• Когда вам (возможно) нужно иметь возможность добавить больше функций к этому классу, создав его подкласс.