[Из песочницы] Swift Features
В этой статье хотелось рассказать об особенностях и трудностях Swift, с которыми я столкнулся при первом знакомстве. Для написания статьи использовалась версия языка 2.0. Предполагается, что вы уже читали документацию и обладаете базовыми знаниями для разработки мобильного приложения.
Под этим термином я подразумеваю любые протоколы, в которых есть открытые typealias (associatedtype в Swift 2.2). В моем первом приложении на Swift было два таких протокола: (для примера я немного упростил их)
DataObservable отвечает за отслеживание изменения данных. При этом не важно, где эти данные хранятся (на сервере, локально или еще как). DataObserver получает оповещения о том, что данные изменились. В первую очередь нас будет интересовать протокол DataObservable, и вот его простейшая реализация.
Тут все просто: сохраняем ссылку на последний observer, и вызываем у него метод didDataChangedNotification, когда данные по какой-то причине изменяются. Но погодите… этот код не компилируется. Компилятор выдает ошибку «Protocol 'DataObserver' can only be used as a generic constraint because it has Self or associated type requirements». Все потому, что generic-протоколы могут использоваться только для накладывания ограничений на generic-параметры. Т.е. объявить переменную типа DataObserver не получится. Меня такое положение дел не устроило. Немного покопавшись в сети, я нашел решение, которое помогает разобраться со сложившейся проблемой, и имя ему Type Erasure.
Тело метода didDataChangedNotification пока оставим пустым. Идем дальше. Вводим в класс generic init (для чего он нужен расскажу чуть ниже):
В него передается параметр sourceObserver типа TObserver. Видно, что на TObserver накладываются ограничения: во-первых он должен реализовать протокол DataObserver, во-вторых его DataType должен в точности соответствовать DataType нашего класса. Собственно sourceObserver это и есть исходный observer-объект, который мы хотим обернуть. И наконец финальный код класса:
Собственно тут и происходит вся «магия». В класс добавляется закрытое поле observerHandler, в котором хранится реализация метода didDataChangedNotification объекта sourceObserver. В самом методе didDataChangedNotification нашего класса мы просто вызываем эту реализацию.
Теперь код компилируется и прекрасно работает. Могу отметить, что некоторые классы из стандартной библиотеки Swift работают по схожему принципу (например AnySequence).
В определенный момент мне потребовалось ввести в проект протокол копирования:
Все бы хорошо, но этот код не скомпилируется: «Cannot convert return expression of type ViewController to return type 'Self'» Дело в том, что компилятор не может преобразовать ViewController к Self. В данном случае ViewController и Self — это одно и то же, но в общем случае это не так (например, при использовании наследования).
Ее назначение — это преобразование объекта одного типа к другому типу. Если преобразование не удается, то функция просто завершается с ошибкой.
Благодаря автоматическому выводу типов, newInstance теперь преобразуется к Self (чего нельзя было сделать напрямую). Этот код компилируется и работает.
Расширения типов в Swift не были бы такими полезными, если бы нельзя было писать специфичный код для разных типов. Возьмем, к примеру, протокол SequenceType из стандартной библиотеки и напишем для него такое расширение:
В расширении введено ограничение на элемент последовательности, он должен быть типа String. Таким образом для любой последовательности, состоящей из строк (и только для них), можно будет вызвать функцию concat.
Это позволяет значительную часть кода выносить в расширения, и вызывать его в нужном контексте, получая при этом все плюсы повторного использования.
Реализация методов протокола по умолчанию.
Как следует из описания, любой тип реализующий этот протокол, должен обладать уникальным идентификатором uniqueId типа String. Но если немного подумать, то становится понятно, что в рамках одного модуля для любого типа уникальным идентификатором является его название. Так давайте напишем расширение для нашего нового протокола:
В данном случае ключевое слово Self используется для того, чтобы накладывать ограничения на объект-тип. Логика этого кода примерно следующая: «если этот протокол будет реализован классом UIViewController (или его наследником), то можно использовать следующую реализацию uniqueId». Это и есть реализация протокола по-умолчанию. На самом деле можно написать это расширение и без каких-либо ограничений:
И тогда все типы, реализующие UniqueIdentifierProvider, получат uniqueId «из коробки».
Прелесть в том, что в классе может быть своя реализация этого метода. И в этом случае реализация по-умолчанию будет игнорироваться:
В своем проекте я использовал MVVM, и за создание ViewModel отвечал метод:
В данном случае в функцию createViewModel в качестве generic аргумента будет поставляться MyViewModel. Все благодаря тому, что Swift сам выводит типы из контекста. Но всегда ли это хорошо? На мой взгляд, это не так. В некоторых случаях может даже привести к ошибкам:
После этого наш switch-case выглядит так:
Теперь В функцию createViewModel передается аргументы NormalViewModel.self и PreviewViewModel.self. Это объекты-типы NormalViewModel и PreviewViewModel. В Swift есть довольно странная особенность: если у функции один параметр, можно не писать self.
Надеюсь что данная статья окажется кому-то полезной. Так же планируется продолжение про Swift (и не только).
Generic протоколы
Под этим термином я подразумеваю любые протоколы, в которых есть открытые typealias (associatedtype в Swift 2.2). В моем первом приложении на Swift было два таких протокола: (для примера я немного упростил их)
public protocol DataObserver {
typealias DataType
func didDataChangedNotification(data: DataType)
}
public protocol DataObservable {
typealias DataType
func observeData (observer: TObserver)
}
DataObservable отвечает за отслеживание изменения данных. При этом не важно, где эти данные хранятся (на сервере, локально или еще как). DataObserver получает оповещения о том, что данные изменились. В первую очередь нас будет интересовать протокол DataObservable, и вот его простейшая реализация.
public class SimpleDataObservable : DataObservable {
public typealias DataType = TData
private var observer: DataObserver?
public var data: DataType {
didSet {
observer?.didDataChangedNotification(data)
}
}
public init(data: TData) {
self.data = data
}
public func observeData(observer: TObserver) {
self.observer = observer
}
}
Тут все просто: сохраняем ссылку на последний observer, и вызываем у него метод didDataChangedNotification, когда данные по какой-то причине изменяются. Но погодите… этот код не компилируется. Компилятор выдает ошибку «Protocol 'DataObserver' can only be used as a generic constraint because it has Self or associated type requirements». Все потому, что generic-протоколы могут использоваться только для накладывания ограничений на generic-параметры. Т.е. объявить переменную типа DataObserver не получится. Меня такое положение дел не устроило. Немного покопавшись в сети, я нашел решение, которое помогает разобраться со сложившейся проблемой, и имя ему Type Erasure.
Это паттерн, который представляет собой небольшой обертку над заданным протоколом. Для начала введем новый класс AnyDataObserver, который реализует протокол DataObserver.
public class AnyDataObserver : DataObserver {
public typealias DataType = TData
public func didDataChangedNotification(data: DataType) {
}
}
Тело метода didDataChangedNotification пока оставим пустым. Идем дальше. Вводим в класс generic init (для чего он нужен расскажу чуть ниже):
public class AnyDataObserver : DataObserver {
public typealias DataType = TData
public func didDataChangedNotification(data: DataType) {
}
public init(sourceObserver: TObserver) {
}
}
В него передается параметр sourceObserver типа TObserver. Видно, что на TObserver накладываются ограничения: во-первых он должен реализовать протокол DataObserver, во-вторых его DataType должен в точности соответствовать DataType нашего класса. Собственно sourceObserver это и есть исходный observer-объект, который мы хотим обернуть. И наконец финальный код класса:
public class AnyDataObserver : DataObserver {
public typealias DataType = TData
private let observerHandler: TData -> Void
public func didDataChangedNotification(data: DataType) {
observerHandler(data)
}
public init(sourceObserver: TObserver) {
observerHandler = sourceObserver.didDataChangedNotification
}
}
Собственно тут и происходит вся «магия». В класс добавляется закрытое поле observerHandler, в котором хранится реализация метода didDataChangedNotification объекта sourceObserver. В самом методе didDataChangedNotification нашего класса мы просто вызываем эту реализацию.
Теперь перепишем SimpleDataObservable:
public class SimpleDataObservable : DataObservable {
public typealias DataType = TData
private var observer: AnyDataObserver?
public var data: DataType {
didSet {
observer?.didDataChangedNotification(data)
}
}
public init(data: TData) {
self.data = data
}
public func observeData(observer: TObserver) {
self.observer = AnyDataObserver(sourceObserver: observer)
}
}
Теперь код компилируется и прекрасно работает. Могу отметить, что некоторые классы из стандартной библиотеки Swift работают по схожему принципу (например AnySequence).
Тип Self
В определенный момент мне потребовалось ввести в проект протокол копирования:
public protocol CopyableType {
func copy() -> ???
}
Но что же должен возвращать метод copy? Any? CopyableType? Тогда при каждом вызове пришлось бы писать let copyObject = someObject.copy as! SomeClass, что не очень хорошо. В добавок к тому же этот код небезопасен. На помощь приходит ключевое слово Self.
public protocol CopyableType {
func copy () → Self
}
Таким образом мы сообщаем компилятору, что реализация этого метода обязана вернуть объект того же типа, что и объект, для которого он был вызван. Тут можно провести аналогию с instancetype из Objective-C.
Рассмотрим реализацию этого протокола:
public class CopyableClass: CopyableType {
public var fieldA = 0
public var fieldB = "Field"
public required init() {
}
public func copy() -> Self {
let copy = self.dynamicType.init()
copy.fieldA = fieldA
copy.fieldB = fieldB
return copy
}
}
Для создание нового экземпляра используется ключевое слово dynamicType (получение ссылки на динамический объект-тип) и вызывается метод init (для гарантии того, что init без параметров действительно есть в классе, мы вводим его с ключевым словом required). После чего копируем в созданный экземпляр все нужные поля и возвращаем его из нашей функции.
Как только я закончил с копированием, возникла необходимость использовать Self еще в одном месте. Мне потребовалось написать протокол для View Controller, в котором бы был статический метод создания нового экземпляра этого самого View Controller.
Так как этот протокол никак напрямую не был связан с классом UIViewController, то я его сделал достаточно общим и назвал AutofactoryType:
public protocol AutofactoryType {
static func createInstance() -> Self
}
Попробуем использовать его для создания View Conotroller:
public class ViewController: UIViewController, AutofactoryType {
public static func createInstance() -> Self {
let newInstance = UIStoryboard(name: "Main", bundle: nil).instantiateViewControllerWithIdentifier("ViewController")
return newInstance as! ViewController
}
}
Все бы хорошо, но этот код не скомпилируется: «Cannot convert return expression of type ViewController to return type 'Self'» Дело в том, что компилятор не может преобразовать ViewController к Self. В данном случае ViewController и Self — это одно и то же, но в общем случае это не так (например, при использовании наследования).
Как же заставить этот код работать? Для этого есть не совсем честный (по отношению к строгой типизации), но вполне рабочий способ. Добавим функцию:
public func unsafeCast(sourceValue: T) -> E {
if let castedValue = sourceValue as? E {
return castedValue
}
fatalError("Unsafe casting value \(sourceValue) to type \(E.self) failed")
}
Ее назначение — это преобразование объекта одного типа к другому типу. Если преобразование не удается, то функция просто завершается с ошибкой.
Используем эту функцию в createInstance:
public class ViewController: UIViewController, AutofactoryType {
public static func createInstance() -> Self {
let newInstance = UIStoryboard(name: "Main", bundle: nil).instantiateViewControllerWithIdentifier("ViewController")
return unsafeCast(newInstance)
}
}
Благодаря автоматическому выводу типов, newInstance теперь преобразуется к Self (чего нельзя было сделать напрямую). Этот код компилируется и работает.
Специфичные расширения
Расширения типов в Swift не были бы такими полезными, если бы нельзя было писать специфичный код для разных типов. Возьмем, к примеру, протокол SequenceType из стандартной библиотеки и напишем для него такое расширение:
extension SequenceType where Generator.Element == String {
public func concat() -> String {
var result = String()
for value in self {
result += value
}
return result
}
}
В расширении введено ограничение на элемент последовательности, он должен быть типа String. Таким образом для любой последовательности, состоящей из строк (и только для них), можно будет вызвать функцию concat.
func test() {
let strings = ["Alpha”, "Beta”, "Gamma”]
//printing "AlphaBetaGamma”
print("Strings concat: \(strings.concat())")
}
Это позволяет значительную часть кода выносить в расширения, и вызывать его в нужном контексте, получая при этом все плюсы повторного использования.
Реализация методов протокола по умолчанию.
Реализация методов протокола по умолчанию.
public protocol UniqueIdentifierProvider {
static var uniqueId: String { get }
}
Как следует из описания, любой тип реализующий этот протокол, должен обладать уникальным идентификатором uniqueId типа String. Но если немного подумать, то становится понятно, что в рамках одного модуля для любого типа уникальным идентификатором является его название. Так давайте напишем расширение для нашего нового протокола:
extension UniqueIdentifierProvider where Self: UIViewController {
static var uniqueId: String {
get {
return String(self)
}
}
}
В данном случае ключевое слово Self используется для того, чтобы накладывать ограничения на объект-тип. Логика этого кода примерно следующая: «если этот протокол будет реализован классом UIViewController (или его наследником), то можно использовать следующую реализацию uniqueId». Это и есть реализация протокола по-умолчанию. На самом деле можно написать это расширение и без каких-либо ограничений:
extension UniqueIdentifierProvider {
static var uniqueId: String {
get {
return String(self)
}
}
}
И тогда все типы, реализующие UniqueIdentifierProvider, получат uniqueId «из коробки».
extension ViewController: UniqueIdentifierProvider {
//Nothing
}
func test() {
//printing "ViewController"
print(ViewController.uniqueId)
}
Прелесть в том, что в классе может быть своя реализация этого метода. И в этом случае реализация по-умолчанию будет игнорироваться:
extension ViewController: UniqueIdentifierProvider {
static var uniqueId: String {
get {
return "I’m ViewController”
}
}
}
func test() {
//printing "I’m ViewController"
print(ViewController.uniqueId)
}
Явное указание Generic аргумента
В своем проекте я использовал MVVM, и за создание ViewModel отвечал метод:
public func createViewModel() -> TViewModel {
let viewModel = TViewModel.createIntsance()
//View model configurate
return viewModel
}
Соответственно, так он использовался:
func test() {
let viewModel: MyViewModel = createViewModel()
}
В данном случае в функцию createViewModel в качестве generic аргумента будет поставляться MyViewModel. Все благодаря тому, что Swift сам выводит типы из контекста. Но всегда ли это хорошо? На мой взгляд, это не так. В некоторых случаях может даже привести к ошибкам:
func test(mode: FactoryMode) -> ViewModelBase {
switch mode {
case NormalMode:
return createViewModel() as NormalViewModel
case PreviewMode:
return createViewModel() //забыли as PreviewViewModel
}
}
В первом case в метод createViewModel подставляется NormalViewModel.
Во втором мы забыли написать «as PreviewViewModel», из-за чего в метод createViewModel подставляется тип ViewModelBase (что в лучшем случае приведет к ошибке в runtime).
Значит, необходимо сделать указание типа явным. Для этого в createViewModel мы добавим новый параметр viewModelType типа TViewModel.Type. Type тут означает, что метод принимает в качестве параметра не экземпляр типа, а сам объект-тип.
public func createViewModel(viewModelType: TViewModel.Type) -> TViewModel {
let viewModel = viewModelType.createIntsance()
//View model configurate
return viewModel
}
После этого наш switch-case выглядит так:
func test(mode: FactoryMode) {
let viewModel: ViewModelBase?
switch mode {
case NormalMode:
return createViewModel(NormalViewModel.self)
case PreviewMode:
return createViewModel(PreviewViewModel.self)
}
}
Теперь В функцию createViewModel передается аргументы NormalViewModel.self и PreviewViewModel.self. Это объекты-типы NormalViewModel и PreviewViewModel. В Swift есть довольно странная особенность: если у функции один параметр, можно не писать self.
func test(mode: FactoryMode) {
let viewModel: ViewModelBase?
switch mode {
case NormalMode:
return createViewModel(NormalViewModel)
case PreviewMode:
return createViewModel(PreviewViewModel)
}
}
Но если аргументов два или больше, ключевое слово self необходимо.
P. S.
Надеюсь что данная статья окажется кому-то полезной. Так же планируется продолжение про Swift (и не только).
