Subclassing v.s. Protocols

Question

Lets begin with the Class approach:

class LoginCredentials {

    var id : String

    init(userID:String) {
        self.id = userID
    }
}

then we will have the following:

class FacebookLoginCredentials : LoginCredentials {

var token : String
init(userID:String,userToken:String) {

    self.token = userToken    
    super.init(userID: userID)
}}

And

class TwitterLoginCredentials  : LoginCredentials {
var token : String
var secret : String
init(userID:String,userToken:String,secret : String) {

    self.token = userToken
    self.secret = secret
    super.init(userID: userID)
}
}

The second Approach is the Protocol Oriented if I am not wrong

protocol LoginCredentials {

    var id : String { get }
}

then we will have :

struct FacebookLoginCredentials : LoginCredentials {

var id: String
var token : String
init(userID:String,userToken:String) {

    self.id = userID
    self.token = userToken
}
}

And

struct TwitterLoginProfile : LoginCredentials {
var id: String
var token : String
var secret : String

init(userID:String,userToken:String,secret : String) {

    self.token = userToken
    self.secret = secret
    self.id = userID
}
}

I just need to know which one is more Swift ?

Protocols are mostly used for delegation. The subclassing here is the better option in my opinion. — milo526, Nov 04 '15 at 15:11
@milo526 Protocols are far from only used for delegation. That is a very "objective-c" way of look at things. I encourage you to watch https://developer.apple.com/videos/play/wwdc2015-408/ or read http://www.raywenderlich.com/109156/introducing-protocol-oriented-programming-in-swift-2 — drewag, Nov 05 '15 at 18:04

score 2 · Answer 1 · answered Nov 04 '15 at 15:11

Either or is acceptable in swift.

Here is how you want to distinguish from the two.

When working with Protocols, you want to treat these as if they were blue prints for your objects.

Ballplayers must know what a ball is, so any person that wants to be a Ballplayer must know what a ball is.

You have a set of rules you want certain objects to follow, make a protocol.

If you want to make objects that have functionality, and you want the children to inherent this functionality, and then have more functionality, then do the inheret class structure.

Dad can throw a ball at 100MPH Junior can throw a ball at 100MPH and throw a curve ball.

This would be done with a class, not protocol

This answer doesn't seem to include any thought about protocol extensions. It is still possible to add functionality to a protocol, it just can't use inheritance. — drewag, Nov 05 '15 at 18:06
That is because extending protocol goes beyond what a protocol does, that is why it is done in an extension — Knight0fDragon, Nov 05 '15 at 18:35

score 2 · Accepted Answer · edited May 23 '17 at 12:33

Ultimately, neither of these approaches is "more Swift". In Swift, you will sometimes want to use inheritance and other times you will want to use protocols. The real decision point for these two approaches is:

Do you want value type semantics (structs and protocols) or do you want reference type semantics (classes and protocols). I usually default to value type semantics because they are safer but there are definitely circumstances where reference type semantics are important. You can read more about that here: Why Choose Struct over Class.

score 1 · Answer 3 · edited May 23 '17 at 11:52

Structure instances are always passed by value, and class instances are always passed by reference. This means that they are suited to different kinds of tasks. As you consider the data constructs and functionality that you need for a project, decide whether each data construct should be defined as a class or as a structure.

As a general guideline, consider creating a structure when one or more of these conditions apply:

The structure’s primary purpose is to encapsulate a few relatively simple data values. It is reasonable to expect that the encapsulated values will be copied rather than referenced when you assign or pass around an instance of that structure. Any properties stored by the structure are themselves value types, which would also be expected to be copied rather than referenced. The structure does not need to inherit properties or behavior from another existing type. Examples of good candidates for structures include:

The size of a geometric shape, perhaps encapsulating a width property and a height property, both of type Double.

A way to refer to ranges within a series, perhaps encapsulating a start property and a length property, both of type Int.

A point in a 3D coordinate system, perhaps encapsulating x, y and z properties, each of type Double.

In all other cases, define a class, and create instances of that class to be managed and passed by reference. In practice, this means that most custom data constructs should be classes, not structures.

Why Choose Struct Over Class?

Subclassing v.s. Protocols

3 Answers3

Linked