Комментарии 24
Константы лучше переменных? Даже безотносительно детсадовской постановки вопроса «мама лучше папы» — человеческий подход к проблеме «хочу везде поменять цвет» называется dependency injection.
-3
Синглтон — это единственный экземпляр класса, который всегда присутствует в памяти. И что в нем особенного? Предположим, вы создаете приложение, которое подключается к базе данных, и вам нужно куда-то разместить все подключения. Синглтоны для этого подойдут идеально.
Di для этого подойдут идеально
+4
Часто di предпочтительней, согласен. Подробнее про di: www.objc.io/issues/15-testing/dependency-injection
0
Ошибка в примере:
Хотя должно быть:
Плюсом, нельзя забывать о такой конструкции:
func setupApp() {
if let theThing = someVariable {
self.somethingElse = self.someVariable!
} else {
print("error")
}
}
Хотя должно быть:
func setupApp() {
if let theThing = someVariable {
self.somethingElse = theThing // Значение уже развернуто в theThing
} else {
print("error")
}
}
Плюсом, нельзя забывать о такой конструкции:
guard let theThing = someVariable else { return } // В блоке else обязательно должен быть шаг вперёд(например continue) или return.
theThing.doSomething()
+3
Существует множество вариаций MVC, например, MVVM и MVP. О них стоит почитать, но принцип их работы схож с MVC
Не совсем. MVC — архитектурный паттерн, два других, которые вы назвали, — это не вариации, а два других архитектурных паттерна. Лучше бы написать как-то так: «существуют и другие архитектурные шаблоны проектирования, такие, как MVP, MVVM, VIPER, но их рассмотрение выходит за рамки данной статьи». Принципы у них ни разу не схожи.
+4
Вы забыли указать, что опционалы — это ни что иное, как синтаксический сахар, внутри которого скрываются простые генерик перечисления со значениями .none и .some(T). Соответственно, не возбраняется их разворачивать switch/case'ом.
Второе, в вашем синглтоне не скрыт инициализатор и ничто не помешает вызвать его
Так же стоит заметить, что Nil Coalescing работает медленно, и использовать его в больших количествах и в сложных выражениях стоит аккуратнее, иначе сборка может затянутся или вообще компилятор откажется собирать проект с сообщением:
Второе, в вашем синглтоне не скрыт инициализатор и ничто не помешает вызвать его
let service = DataService()
Так же стоит заметить, что Nil Coalescing работает медленно, и использовать его в больших количествах и в сложных выражениях стоит аккуратнее, иначе сборка может затянутся или вообще компилятор откажется собирать проект с сообщением:
Expression was too complex to be solved in reasonable time
+2
Я не iOS программист. После прочтения поста возникает вопрос.
iOS только приходит к нормальной разработке через общепринятые паттерны, или автор пишет про широко известные вещи?
Я думаю, что, скорее, второе. Если так, то он может относиться к любому языку и звучать как «ешь твердое вилкой, а жидкое ложкой»
iOS только приходит к нормальной разработке через общепринятые паттерны, или автор пишет про широко известные вещи?
Я думаю, что, скорее, второе. Если так, то он может относиться к любому языку и звучать как «ешь твердое вилкой, а жидкое ложкой»
+1
В синглтоне тоже не все гладко.
Правильный вот:
class Singleton {
static let shared = Singleton()
private init() {}
}
+2
Зачем писать init, если он есть по умолчанию?
-1
Более правильно будет
final class Singleton {
...
}
0
Правильный синглтон — отсутствующий синглтон.
Ибо такой синглтон, практически всегда, есть неявная зависимость.
-1
А можно и так:
enum SomeManager {
static var someVar: String?
static func someFunc() -> Int {
return 0
}
}
-1
а в офф. доках разве не тоже самое?)
0
Обещаем приятный подарок от Программы ЕФС автору самого оригинального рассказа!
Высылайте подарок Саше.
Cписок историй:
Short fairytales with unhappy endings.
+1
1. Так чем константы лучше переменных? Был приведен способ использования констант — в качестве глобальных значений, но это же не преимущество по сравнению с переменными. Переменная тоже это может. Преимущества то в другом — в том что константы — это неизменяемые значения, это значит что: компилятор может проводить с ними определенные оптимизации; они потокобезопасны (так как доступны только на чтение).
2. Не всегда force unwrap это ошибка. Иногда это нужно, например, для того, чтобы указать, что переменная не может быть nil, но установить значение сразу мы ей не можем (пример — outlets). Когда точно известно, что значение не может быть nil (пример — UIImage(named: «img»)! — так даже легче не забыть добавить ресурс).
Слово singleton встречается в тексте подозрительно часто, это гипноз?! Сейчас прочитает это какой-нибудь начинающий разработчик и начнет синглтоны клепать где попало. Вы же наверняка знаете проблемы синглтонов, напишите — будет полезно.
2. Не всегда force unwrap это ошибка. Иногда это нужно, например, для того, чтобы указать, что переменная не может быть nil, но установить значение сразу мы ей не можем (пример — outlets). Когда точно известно, что значение не может быть nil (пример — UIImage(named: «img»)! — так даже легче не забыть добавить ресурс).
Слово singleton встречается в тексте подозрительно часто, это гипноз?! Сейчас прочитает это какой-нибудь начинающий разработчик и начнет синглтоны клепать где попало. Вы же наверняка знаете проблемы синглтонов, напишите — будет полезно.
+2
По пунктам 1 и 2 — согласен, Вы правы.
По поводу синглтонов. Специально для начинающих разработчиков — не надо клепать синглтоны где попало :) Бездумное использование глобальных переменных (пусть даже обернутых в синглтон) не есть признак хорошей архитектуры, часто без него можно обойтись (например, с помощью dependency injection, как справедливо заметили здесь). Из минусов синглтонов я бы выделил сложность их тестирования. Модульное тестирование предполагает независимость тестов друг от друга (т.е. по-хорошему их можно запускать в любой очередности). Если какой-то тест изменяет некоторую переменную в синглтоне, а другой тест использует ее значение, то получаем зависимость между тестами.
Более подробно про проблемы синглтонов в статье: www.objc.io/issues/13-architecture/singletons
По поводу синглтонов. Специально для начинающих разработчиков — не надо клепать синглтоны где попало :) Бездумное использование глобальных переменных (пусть даже обернутых в синглтон) не есть признак хорошей архитектуры, часто без него можно обойтись (например, с помощью dependency injection, как справедливо заметили здесь). Из минусов синглтонов я бы выделил сложность их тестирования. Модульное тестирование предполагает независимость тестов друг от друга (т.е. по-хорошему их можно запускать в любой очередности). Если какой-то тест изменяет некоторую переменную в синглтоне, а другой тест использует ее значение, то получаем зависимость между тестами.
Более подробно про проблемы синглтонов в статье: www.objc.io/issues/13-architecture/singletons
0
Чем дальше, тем больше swift напоминает Delphi. Вот и до констант уже добрались, и синглтоны полюбили )
-1
Я вообще считаю, что сколько людей — столько и версий синглтона.
(с) книга «Хрестоматия iOS паттернов. На всякий»
(с) книга «Хрестоматия iOS паттернов. На всякий»
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Три ошибки iOS-разработчика, которые могут дорого стоить