По моему опыту, разработка для чрезмерно общего случая имеет тенденцию порождать слишком много сложности.
Техническая культура поощряет проекты, которые делают меньше предположений о среде; это обычно - хорошая вещь, но некоторые люди берут ее слишком далеко. Например, это могло бы быть хорошим, если Ваш автомобильный дизайн не принимает определенную гравитацию, никто на самом деле не собирается водить Ваш автомобиль на луне, и если бы они сделали, то это не работало бы, потому что нет никакого кислорода, чтобы заставить топливо гореть.
трудная часть - то, что парень, который разрабатывается дизайн "works-on-any-planet", часто рассматривается как умный, таким образом, Вам, вероятно, придется работать усерднее, чтобы утверждать, что его дизайн также умен.
компромиссы Понимания, таким образом, можно принять решение между хорошими предположениями и плохими предположениями, будут иметь большое значение в предотвращение напрасно сложного дизайна.
Если у вас есть подозрение, что это преждевременное удаление, разрешите зомби подтвердить вашу гипотезу, а затем отладьте, что происходит. Когда вы включаете зомби, объекты на самом деле не уничтожаются, а устанавливаются в состояние зомби, что помогает вам определять, когда к ним обращаются после вызова их освобождения. Подробнее см. NSZombieEnabled
Если вы используете NSZombieEnabled, вы можете по крайней мере выяснить, к какому классу принадлежит объект.