Слабые «присваивают» ссылки, а не одиночные

Question

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

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

@property (nonatomic, assign) MyDataClass*mydata;

В пользовательском init классе я передаю ссылку в качестве параметра метода, а затем property присваивает эту ссылку.

Это действительный, приемлемый способ делать вещи? У меня проблемы с нахождением большей части организационного преимущества, чем использование синглетонов.

Answer 1

Шаблон, который вы используете, просто отлично, в конце концов, этот шаблон используется во всех стандартных программах на C ++ без подсчета ссылок или других расширенных инструментов управления памятью. Единственное, что вы должны убедиться, что ваша иерархия объектов строго учитывает слабость ссылки, то есть зависимость объекта, имеющего ссылку на объект, который находится за этой ссылкой. Другими словами, вы всегда должны убедиться, что владелец ссылки удален до ссылки, и вы должны убедиться в этом вручную, поскольку вы не используете подсчет ссылок.

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

По этой причине я не предлагаю "смешивать" два подхода, то есть иметь слабые ссылки на объект, который может быть выведен из-под контроля с помощью свойства типа retain (когда значение свойства изменяется от вашего объекта), autorelease или ARC.

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

Answer 2

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

Будучи разработчиком java-веб-приложений, Singletons были плохими из-за тесной связи, и особенно потому, что если вы хотите распределить свое приложение по балансировщику нагрузки / (облако сейчас) ... тогда ваш синглтон станет узким местом - и не будет легко масштабируемым.

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

Однако в разработке Objective-C и iOS - я не вижу такого большого количества недостатков для одиночных игр. Ваше приложение не будет масштабироваться, а SDK уже усеян одиночками, чтобы помешать вашим юнит-тестам.

Answer 3

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

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

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