GeoFenceController с CLLocationManager как singleton?

Question

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

Я не могу придумать какую-либо причину, которой это не должно быть, и у меня есть несколько причин; классический «должен быть только один!» а также что класс действительно не имеет каких-либо зависимостей, насколько я могу судить, кроме объекта locationManager, который он мог бы создать, так как он не нужен нигде в другом месте, и я не считаю, что какие-либо специальные реализации могли бы когда-либо потребуется. По этой причине я не вижу смысла вводить locationManager. Также необходимо использовать в приложении другой общий экземпляр, который вызывает сервер для извлечения некоторых данных. Самая важная причина сделать это синглтон, я думаю, это то, что он отслеживает контролируемые регионы и хранит некоторые данные, связанные с этим, и некоторые временные метки и другие незначительные вещи в NSUserDefaults. Другой пример класса, который я боюсь, может привести к непоследовательному поведению приложения.

Мой код предназначен для добавления в существующее приложение в качестве расширения.

Я не думаю, что отправка моего кода действительно актуальна, но я кратко объясню, что делает класс: При создании экземпляра он начнет отслеживать местоположение пользователей и продолжит делать это в фоновом режиме. Он запросит список мест с сервера и получит их на основе текущего местоположения устройства. Эти местоположения будут отсортированы и сохранены, а 20 мест, ближайших к устройству, будут отслеживаться для входа. Это в значительной степени основы этого. Geofencing.

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

Answer 1

GeoFenceController будет использовать глобальный ресурс - пул из 20 регионов, доступных вашему приложению. Этот пул реализован таким образом, что не только пропускная способность распределяется между всеми экземплярами CLLocationManager, все регионы будут эффективно совместно использоваться, так как все экземпляры CLLocationManager будут сообщать о событиях ввода/выхода для своих делегатов для всех регионов , Ограничения пропускной способности и «собственные» события приведут к запутанному коду.

Именно поэтому одноэлементный шаблон здесь довольно приемлем.