Search
Write a publication
Pull to refresh

Comments 6

Можно пояснить вот этот момент?
Что значит лишает нас гарантии?


Изменение таких полей будет невозможным, если не объявить мутабельным и новый экземпляр структуры, а это лишает гарантии, что он не модифицируется где-то еще

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


Например, в случае захвата экземпляров структур в замыкании фактически это происходит по ссылке, пока не будет явно указано обратное ([steveJobs] in):


func doSomething(closure: @escaping () -> Void) {
    DispatchQueue.main.async {
        closure()
    }
}

let steve = User(id: 1, name: "Steve", age: 21)

var steveJobs = steve
steveJobs.name = "Steve Jobs"

doSomething {
    print(steveJobs.age) // Распечатается 41
}

steveJobs.age = 41

Разработчики могут легко пропустить такие тонкости, ожидая захват копированием того состояния, который был до выполнения метода doSomething. В случае же немутабельных экземпляров в этом плане все безопаснее.

Ну данный пример это скорее плохие практики кода. Мое личное мнение что ваше решение хоть и интересное но избыточное.

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


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

This! Согласен на все 100, в начале было не совсем понятно зачем это нужно и когда применять, но позже для себя увидел применения в больших моделях или при частом копировании/изменении. Круто, спасибо!
Очень полезная практика, особенно для структур с большим количеством свойств, которое много где используется. И когда собирать такую структуру надо на 3-х экранах через builder. Спасибо!
Sign up to leave a comment.