Вычисляемое свойство только для чтения против функции в Swift

Во введении в сеанс Swift WWDC descriptionдемонстрируется свойство только для чтения :

class Vehicle {
    var numberOfWheels = 0
    var description: String {
        return "\(numberOfWheels) wheels"
    }
}

let vehicle = Vehicle()
println(vehicle.description)

Есть ли какие-либо последствия для выбора вышеуказанного подхода вместо использования метода:

class Vehicle {
    var numberOfWheels = 0
    func description() -> String {
        return "\(numberOfWheels) wheels"
    }
}

let vehicle = Vehicle()
println(vehicle.description())

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

• Семантика - в этом примере имеет смысл descriptionбыть свойством класса, а не действием, которое он выполняет.
• Краткость / Четкость - предотвращает необходимость использования пустых скобок при получении значения.

Очевидно, что приведенный выше пример слишком прост, но есть ли другие веские причины выбрать один из них? Например, есть ли какие-то особенности функций или свойств, которые помогут вам решить, какие из них использовать?

NB. На первый взгляд это кажется довольно частым вопросом ООП, но я очень хочу знать о каких-либо специфических для Swift функциях, которые могли бы служить руководством для наилучшей практики использования этого языка.

Мне кажется , что это в основном вопрос стиля: я сильно предпочитаю использовать свойства только для этого: свойства; означает простые значения, которые вы можете получить и / или установить. Я использую функции (или методы), когда выполняется реальная работа. Возможно, что-то нужно вычислить или прочитать с диска или из базы данных: в этом случае я использую функцию, даже если возвращается только простое значение. Таким образом, я могу легко увидеть, является ли вызов дешевым (свойства) или, возможно, дорогим (функции).

Мы, вероятно, получим больше ясности, когда Apple опубликует некоторые соглашения о кодировании Swift.

Что ж, вы можете применить советы Котлина https://kotlinlang.org/docs/reference/coding-conventions.html#functions-vs-properties .

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

Предпочитайте свойство функции, когда базовый алгоритм:

• не бросает
• сложность рассчитывается дешево (или достигается при первом запуске)
• возвращает тот же результат по вызовам

Хотя вопрос о вычисленных свойствах и методах в целом является сложным и субъективным, в настоящее время в случае Swift есть один важный аргумент в пользу предпочтения методов над свойствами. Вы можете использовать методы в Swift как чистые функции, что неверно для свойств (начиная с бета-версии Swift 2.0). Это делает методы намного более мощными и полезными, поскольку они могут участвовать в функциональной композиции.

func fflat<A, R>(f: (A) -> () -> (R)) -> (A) -> (R) {
    return { f($0)() }
}

func fnot<A>(f: (A) -> Bool) -> (A) -> (Bool) {
    return { !f($0) }
}

extension String {
    func isEmptyAsFunc() -> Bool {
        return isEmpty
    }
}

let strings = ["Hello", "", "world"]

strings.filter(fnot(fflat(String.isEmptyAsFunc)))

Поскольку среда выполнения такая же, этот вопрос относится и к Objective-C. Я бы сказал, со свойствами вы получаете

• возможность добавить сеттер в подкласс, сделав свойство readwrite
• возможность использовать KVO / didSetдля уведомлений об изменениях
• в более общем случае вы можете передать свойство методам, которые ожидают ключевые пути, например, сортировка запроса на выборку

Что касается чего-то особенного для Swift, единственный у меня пример - это то, что вы можете использовать @lazyдля свойства.

Есть разница: если вы используете свойство, вы можете в конечном итоге переопределить его и сделать чтение / запись в подклассе.

В случае только для чтения, вычисляемое свойство следует не считать семантический эквивалентно методой, даже если они ведут себя одинаково, потому что сбросив funcдекларацию стирает различие между величинами , которые включают состояние экземпляра и количеством , которые являются лишь функциями из штат. Вы экономите на вводе текста ()на сайте вызова, но рискуете потерять ясность в своем коде.

В качестве тривиального примера рассмотрим следующий векторный тип:

struct Vector {
    let x, y: Double
    func length() -> Double {
        return sqrt(x*x + y*y)
    }
}

Объявляя длину как метод, становится ясно, что это функция состояния, которое зависит только от xи y.

С другой стороны, если бы вы выразили lengthвычисленное свойство

struct VectorWithLengthAsProperty {
    let x, y: Double
    var length: Double {
        return sqrt(x*x + y*y)
    }
}

затем, когда вы выполняете dot-tab-complete в своей среде IDE на экземпляре VectorWithLengthAsProperty , это будет выглядеть , как будто x, y, lengthбыли свойства на равных, что концептуально неверно.

Бывают ситуации, когда вы предпочитаете вычисляемое свойство обычным функциям. Например: возврат полного имени человека. Вы уже знаете имя и фамилию. Так что на самом деле fullNameсвойство - это свойство, а не функция. В данном случае это вычисляемое свойство (поскольку вы не можете установить полное имя, вы можете просто извлечь его, используя имя и фамилию)

class Person{
    let firstName: String
    let lastName: String
    init(firstName: String, lastName: String){
        self.firstName = firstName
        self.lastName = lastName
    }
    var fullName :String{
        return firstName+" "+lastName
    }
}
let william = Person(firstName: "William", lastName: "Kinaan")
william.fullName //William Kinaan

С точки зрения производительности разницы нет. Как вы можете видеть в результате теста.

суть

main.swift фрагмент кода:

import Foundation

class MyClass {
    var prop: Int {
        return 88
    }

    func foo() -> Int {
        return 88
    }
}

func test(times: u_long) {
    func testProp(times: u_long) -> TimeInterval {
        let myClass = MyClass()
        let starting = Date()
        for _ in 0...times {
            _ = myClass.prop
        }
        let ending = Date()
        return ending.timeIntervalSince(starting)
    }


    func testFunc(times: u_long) -> TimeInterval {
        let myClass = MyClass()
        let starting = Date()
        for _ in 0...times {
            _ = myClass.prop
        }
        let ending = Date()
        return ending.timeIntervalSince(starting)
    }

    print("prop: \(testProp(times: times))")
    print("func: \(testFunc(times: times))")
}

test(times: 100000)
test(times: 1000000)
test(times: 10000000)
test(times: 100000000)

Вывод:

prop: 0.0380070209503174 func: 0.0350250005722046 prop: 0.371925950050354 func: 0.363085985183716 prop: 3.4023300409317 func: 3.38373708724976 prop: 33.5842199325562 func: 34.8433820009232 Program ended with exit code: 0

В диаграмме:

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

С другой стороны, методы исходят из коробки с предположением, что мы не всегда можем получать одинаковые результаты, потому что Swift не имеет способа пометить функции как чистые. Кроме того, методы в ООП считаются действиями, а это означает, что их выполнение может привести к побочным эффектам. Если у метода нет побочных эффектов, его можно безопасно преобразовать в вычисляемое свойство.

Обратите внимание, что оба приведенных выше утверждения основаны исключительно на семантической перспективе, так как вычисленные свойства могут иметь побочные эффекты, которых мы не ожидаем, а методы - чистыми.

Исторически описание является свойством NSObject, и многие ожидают, что оно останется таким же и в Swift. Добавление паренов после этого только добавит путаницы.

РЕДАКТИРОВАТЬ: после яростного отрицательного голосования я должен кое-что уточнить - если к нему обращаются через точечный синтаксис, это можно рассматривать как свойство. Неважно, что под капотом. Вы не можете получить доступ к обычным методам с точечным синтаксисом.

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