Комментарии 7
Первая строка в классе:
fileprivate lazy var syncQueue:DispatchQueue = Dispatch.DispatchQueue(label: "", qos: .userInteractive)Почему название пустое?
label: ""?
Ага
Если посмотреть детальнее, то есть более колосальная проблема :) — instance может быть не уникальным.
Раз появился syncQueue значит планировалось что-то сделать многопоточным. Это что-то это instance метод. но там допущена ошибка — чтение тоже должно быть в синхронном блоке, иначе много потоков могут дойти до точки синхронизации, и все они создадут по экземпляру объекта.
И пожалуйста, не надо править так: https://ru.wikipedia.org/wiki/Блокировка_с_двойной_проверкой :) на такое тоже часто натыкаюсь :)
P.S. долго думал куда об этом написать, решил всеже развить тему про syncQueue.
P.P.S. На самом деле я не понимаю откуда берется такая любовь к созданию потоков для синхронизации. Вы не один такой, я часто вижу подобный код, но не понимаю чем не устраивает то что созданно для синхронизации, а именно: OSSpinLock или objc_sync_enter/exit. Они быстрее, едят меньше памяти и не нужно создавать странный код чтобы получить значение из тела блока.
О, наконец токи кто-то написал нормально с точки зрения внешнего синтаксиса Typhoon на swift.
Реализация в 200 строчек очень сильно радует — осознал что мои 1к строчек можно видимо оптимизировать.
Правда кое чего думаю не хватит многим:
Внедрение во ViewController так чтобы его не трогать — сейчас я так понял предполагается это делать в функции awakeFromNib, хотелось бы чтобы оно автоматически вызывалось.
Конечно есть много возможностей которые дает регистрация с помощью разделения на register/resolve, но они не сильно критичны для мелких проектах, правда на больших могут дать неплохой буст.
Внедрение во ViewController так чтобы его не трогать — сейчас я так понял предполагается это делать в функции awakeFromNib, хотелось бы чтобы оно автоматически вызывалось.
Увы, красиво у меня пока не получилось. Есть решение со свизлингом )))
В текущем проекте решили жить без Segues, поэтому Assembly сразу выдает ViewController с зависимостями.
А какие возможности дает register/resolve?
Большой список, что-то важно что-то нет:
Валидацию корректности до момента исполнения — в памяти есть полный граф (надуманная проблема, так как в семантике EasyDi проблема может быть помойму только одна — зацикливание, если объявили не objectGraph)
Получение множества объектов по заданному критерию (например есть N реализаций одного протокола)
Уменьшение избыточности синтаксиса — не надо придумывать имена — тип является именем (но есть в этом и преимущество)
Поддержка позднего связывания — к примеру есть протокол, но наличие его реализации не гарантируется, она может быть, а может и не быть. (Та причина почему мы отказались от тайфуна).
Подробнее про позднее связывание:
У нас есть N модулей. В одном модуле описаны протоколы — сервисы. В разных сборках мы имеем разную комбинацию этих модулей, соответственно в разных сборка у нас или есть или нету реализации этих протоколов. Возникает проблема — под каждую сборку надо писать немного разное объявление DI.
Ну и этоже проблема пораждает другую проблему — модульности как такой нету — один Assembly должен знать о другом Assembly из другого модуля, что не всегда приемлимо, см. выше.
Я бы выделил две вещи:
Позднее связывание, очень важная вещь на больших проектах, и мало важная на мелких
Получение множества объектов — упрощает всякие паттерны типа Observer.
Эффективная DI библиотека на Swift в 200 строк кода