Computed read-only property vs function in Swift

后端 未结 10 892
忘了有多久
忘了有多久 2020-12-04 11:00

In the Introduction to Swift WWDC session, a read-only property description is demonstrated:

class Vehicle {
    var numberOfWheels = 0
    var          


        
相关标签:
10条回答
  • 2020-12-04 11:11

    There are situations where you would prefer computed property over normal functions. Such as: returning the full name of an person. You already know the first name and the last name. So really the fullName property is a property not a function. In this case, it is computed property (because you can't set the full name, you can just extract it using the firstname and the lastname)

    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
    
    0 讨论(0)
  • 2020-12-04 11:15

    It seems to me that it's mostly a matter of style: I strongly prefer using properties for just that: properties; meaning simple values that you can get and/or set. I use functions (or methods) when actual work is being done. Maybe something has to be computed or read from disk or from a database: In this case I use a function, even when only a simple value is returned. That way I can easily see whether a call is cheap (properties) or possibly expensive (functions).

    We will probably get more clarity when Apple publishes some Swift coding conventions.

    0 讨论(0)
  • 2020-12-04 11:17

    Well, you can apply Kotlin 's advices https://kotlinlang.org/docs/reference/coding-conventions.html#functions-vs-properties.

    In some cases functions with no arguments might be interchangeable with read-only properties. Although the semantics are similar, there are some stylistic conventions on when to prefer one to another.

    Prefer a property over a function when the underlying algorithm:

    • does not throw
    • complexity is cheap to calculate (or caсhed on the first run)
    • returns the same result over invocations
    0 讨论(0)
  • 2020-12-04 11:22

    Semantically speaking, computed properties should be tightly coupled with the intrinsic state of the object - if other properties don't change, then querying the computed property at different times should give the same output (comparable via == or ===) - similar to calling a pure function on that object.

    Methods on the other hand come out of the box with the assumption that we might not always get the same results, because Swift doesn't have a way to mark functions as pure. Also, methods in OOP are considered actions, which means that executing them might result in side effects. If the method has no side effects, then it can safely be converted to a computed property.

    Note that both of the above statements are purely from a semantic perspective, as it might well happen for computed properties to have side effects that we don't expect, and methods to be pure.

    0 讨论(0)
提交回复
热议问题