This workshop will be retired on May 31, 2020.
Flying5:24 with Pasan Premaratne
Let's start building our objects by creating a few micro protocols.
Before we start writing a bunch of code, let's take a quick step back. 0:00 When we learned about protocols, we talked about their importance. 0:04 A protocol is used to model an object and 0:08 essentially provides a blueprint that the object can conform to. 0:10 By creating many small protocols that model specific aspects, 0:15 we can create a final object through composition. 0:19 This is important because we can create objects that only contain the attributes 0:22 and behaviors they need by conforming to a very specific protocol. 0:27 On the flip side, there's inheritance. 0:31 Inheritance isn't a bad thing. 0:34 But as a design pattern, it can be abused pretty easily. 0:36 And in practice, that's exactly what happens. 0:39 When you create deep subclasses that inherit from many superclasses, 0:42 you get a lot of methods that by default do nothing. 0:46 You override them where you need to provide an implementation. 0:49 UIViewController is full of these examples. 0:53 viewDidLoad does nothing, so 0:56 the actual implementation of these classes contains an empty method. 0:58 Would it be nicer if we had a protocol requirement that we can conform to 1:03 in an extension of the class? 1:06 Perhaps. 1:08 These are the decisions you need to make as you design objects. 1:10 Again, I want to reiterate that inheritance isn't inherently bad. 1:14 But because you can litter your classes with empty methods, Swift prefers that you 1:18 use protocols for a cleaner design, and that's what we're going to try. 1:23 Remember that in Swift, protocols function a tad differently in that we can 1:28 actually provide a default implementation via a protocol extension if we want to. 1:32 This will definitely play a part in the design that we're about to embark on. 1:38 Okay, so let me add a new file to this project. 1:42 And I'm going to write all my code in there so it's just this one file. 1:48 And I'll call it ControlTower. 1:51 The first thing we're going to do is create a set of protocols to model certain 1:59 aspects of an airline. 2:03 I should point out that we're not going to explore the full depths of these models, 2:05 we'll just keep it narrowly focused as always. 2:09 So our first protocol is called flying. 2:12 Another thing I need to point out is that I'm going to be following Swift 2:17 3 naming conventions. 2:20 Now, this workshop is written in Swift 2, so don't worry, but Swift 3 is on 2:23 the horizon, so we might as well start getting used to how to name things. 2:27 The Swift 3 naming guidelines are quite clear and can be found on swift.org. 2:32 I've linked to the relevant sections in the teacher's notes. 2:38 The main rule for this workshop that we're concerned with is naming protocols. 2:41 So protocols that describe what something is should read as a noun, and protocols 2:45 that describe a capability should be named using the suffixes able, ible, or ing. 2:51 Planes can fly, that is, it's a capability. 2:58 So we can either name this as, Flyable, Flyible, or Flying. 3:01 Flying sounds the best of those three, so that's what we're going to go with. 3:06 Now, for this protocol, we're going to add just one requirement. 3:09 We'll say var descentSpeed: Int, 3:14 and we'll say this just needs a getter. 3:18 There are certainly more aspects to flying that we can model, but for 3:24 this example, all we care about is the descent speed. 3:27 Keep in mind that throughout this entire series, 3:31 we're only focusing on a limited example. 3:33 You might think, for example, that it's silly to create a protocol for 3:36 a single requirement, a single property or a single method. 3:40 The Flying protocol could contain more, but 3:43 that would just make our example a bit more complicated to go through. 3:46 Okay, at this point, I'm somewhat rambling, but 3:50 it's worth saying that single requirement protocols are totally okay as well. 3:52 Okay, so back to flying. 3:56 The requirement we added states that conforming types 3:58 should contain a descentSpeed property. 4:01 Now, the type of this property is Int. 4:05 The type doesn't really inform us about the measurement of the property. 4:08 Is this speed in miles per hour, kilometers per hour? 4:12 Who knows. 4:15 We don't have sufficient information to figure that out right now. 4:16 This is a case of weak type information. 4:20 Int doesn't really convey the information that we need, so 4:24 instead what we can do is create a type alias for 4:27 Int that does indicate what speed measurement we're looking for. 4:30 So right after import Foundation, which I don't, 4:35 need I'll type typealias Knots = Int. 4:40 Now, Knots in this case is the speed that we want to measure, and 4:44 it's just another name for the Int type. 4:48 But now, when someone uses our protocol, they immediately 4:51 understand what measurement we're using for our descent speed. 4:54 Now we can change the type over here from Int to Knots. 4:57 Remember, making our code more understandable and 5:01 readable to humans is a very important goal. 5:04 Let's take a break here. 5:07 Before the next video, I do want to point out one thing. 5:08 I know next to nothing about how planes really work. 5:12 So if you do, and this example just sounds ridiculous to you, my apologies. 5:16 Coming up with vaguely interesting examples is a bit hard. 5:20
You need to sign up for Treehouse in order to download course files.Sign up