Swift: refactor singleton pattern

Question

У меня есть одноэлементный класс Swift, который поддерживает состояние приложения, сохраняя несколько массивов. Каков способ наилучшей практики? Должны ли мы изменить его, и если да, то как?

Вот класс синглтон:

import Foundation 


class FilterModel { 
    static let sharedInstance = FilterModel() 
    private init() { } 

    var muscleExercisesArray = [Int]() 
    var equipmentExercisesArray = [Int]() 
    var typeExercisesArray = [Int]() 
} 

Answer 1

Если вы задаетесь вопросом о базовой модели одиночки, пары наблюдений:

1. Я мог бы предложить вам объявить класс быть final , также, чтобы избежать того, чтобы какой-то будущий разработчик подклассифицировал его и представил путаницу в отношении того, что относится к типу sharedInstance.

2. Я мог бы также предположить, что в Swift 3 соглашение должно упростить название sharedInstance до shared. Это не сложное и быстрое правило, а новый стандарт.

3. Эта реализация не является потокобезопасной. Если вы в порядке с этим, я бы по крайней мере включил некоторое предупреждение в комментарии, предупреждающие будущих разработчиков об этой проблеме. Или, очевидно, с небольшой работой вы можете изменить это, чтобы быть потокобезопасным, обернув это все в какой-то механизм внутренней синхронизации.

---

Вы сказали:

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

Да, одиночки не являются идеальными для модельных объектов по ряду причин (упрощает тестирование модулей, делает непонятными и т. д.), и есть лучшие образцы (см. What's Alternative to Singleton). По крайней мере, один простой подход состоит в том, чтобы иметь делегат делегата или контроллер корневого представления, создающий экземпляр этого объекта модели, и затем передавать это только на то, что последующие контроллеры нуждаются в доступе к нему (например, в prepareForSegue). Таким образом, очевидно, какие объекты могут взаимодействовать с моделью, делая обязанности более понятными.