Как отлаживать синглтоны в Objective-C

Question

Мое приложение содержит несколько синглетонов (из этого урока ). Однако я заметил, что когда приложение падает из-за синглтона, становится практически невозможно определить, откуда оно появилось. Точки останова приложения в главной функции дают EXEC_BAD_ACCESS, хотя проблема заключается в одном из объектов Singleton. Есть ли руководство по отладке моих одноэлементных объектов, если бы они были проблематичными?

Answer 1

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

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

Воспроизводимость может быть более сложной в некоторых контекстах, когда / если вы имеете дело со сложным глобальным состоянием, потому что вы создали несколько принудительных синглетонов.когда глобальное состояние достаточно большое и сложное - независимое тестирование этих типов может быть не во всех случаях плодотворным, поскольку ошибка может появляться только в сложном глобальном состоянии, обнаруженном в вашем приложении (когда 4 синглтона взаимодействуют определенным образом).если вы изолировали проблему от взаимодействий нескольких экземпляров-одиночек (например, MONAudioFileCache и MONVideoCache), размещение этих объектов в классе контейнера позволит вам ввести связывание, которое поможет диагностировать это.хотя увеличение связи обычно считается плохой вещью;это на самом деле не увеличивает сцепление (оно уже существует как компоненты глобального состояния), а просто концентрирует существующие глобальные зависимости состояния - вы на самом деле не увеличиваете его так сильно, как концентрируете его, когда состояние этих синглетонов влияет на другие компонентыизменяемого глобального состояния.

, если вы все еще настаиваете на использовании синглетонов, это может помочь:

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

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

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

• проверка ошибок синглетонов проекта должна быть особенно надежной.если программист передает неверный аргумент или неправильно использует интерфейс - просто подтвердите (с хорошим сообщением о проблеме / решении).

• сделайте запись модульных тестов.

• состояние отсоединения (например, если вы можете легко удалить ивар, сделайте это)

• уменьшить сложность состояния.

• , есличто-то все еще невозможно отладить после написания / тестирования с тщательными утверждениями, модульными тестами, тестами на зомби, тестами памяти (GuardMalloc, scribbling) и т. д., вы пишете слишком сложные программы (например, делите сложность между несколькими классами), илитребования не соответствуют фактическому использованию.если вы находитесь в этот момент, вы должны обязательно обратиться к моему другому посту.чем сложнее состояние глобальной переменной, тем больше времени потребуется для отладки, и тем меньше вы сможете повторно использовать и тестировать свои программы, когда что-то пойдет не так.

удачи

Answer 2

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

И, как другие предлагали, если у вас многоСинглтон-объекты могут означать, что вы просто сохраняете слишком большое состояние глобального / постоянного состояния.Обычно требуется только один или два ваших собственных (в дополнение к тем, которые могут быть реализованы другими «пакетами» того или иного рода).

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

Макросы затрудняют отладку, потому что строкикода, который они включают, не могут быть вставлены точки останова.Глубокие шесть макросов, если не больше.В частности, макрос SYNTHESIZE_SINGLETON_FOR_CLASS из статьи мешает отладке.Замените вызов этой макрофункции кодом, который она генерирует для вашего синглтон-класса.

Answer 3

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

большинство реализаций синглтона какао, которые я видел , не должны былиsingletons .

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

хорошая часть - это то, что большинство ваших глобальных переменных требует болиисчезнет при реализации этих классов как обычных объектов.