[MUSIC] The topic is Protocols in the Swift Programming Language, and so before we dig in to the code, we want to talk about what the problem. Is that protocols are addressing so the problem is poor communication. An example we're going to use is databases and data adaptors. Speaking of these different databases, we have a lot of different databases out there, we have Oracle database, Sequel Server database, My Sequel Database MongoDB. And their implementations are completely different, like Oracle is a sequel database and MongoDB is a no-sequel database with completely different implementations. But from a user and a developer level, the functional Interfacing into those, the communication into those databases. The functions that we need to do are pretty common. We need to create records in those databases. We need to read records from those databases. We need to update and delete records. So pretty common functionality across all these databases. So when we create Communication adaptors into those databases, data sources we'll call them. The interfaces into them should be the same. And protocols in the iOS Swift programming language allows us to create different classes. And in this case we're going to create the example's data sources forces us to write our implementations using concrete well-defined interfaces. So the problem, many implementations doing the same task but having different interfaces. And the solution is to create components that communicate the same that have the same interfaces, that we require the same interfaces. And that they are concrete and clear and that they're shared by all of the different implementations. And so we're going to look at the protocol syntax when I look at the verbage for when we speak about protocols that they don't inherit like a class inherits but they can form. So when they type subscribes to a protocol they are considered confirming to that protocol, and protocols can inherit other protocols. So we speak of protocols or classes conforming for protocols, but protocols themselves can inherit other protocols and take in their required properties and methods, and then add additional ones in our derive protocol. So we're going to go ahead, and then we'll also look at protocols as a type and see how that works. We'll go ahead and go to the playground now and look at that. All right here we have a protocol definition, and it looks very much like defining a class. The difference is that, one of the main differences that we aren't defining any method bodies. Here we're defining the properties for this protocol definition. And very much again very much like defining properties in the class where we provide the name and the type. And one different is here we have to specify and a protocol definition for properties whether we can retrieve the property. Whether it's required to retrieve the property or whether it's required to set the property. In this case, both are required and for this property,only retrieving the property is required. For method definition, we specify the method name a method parameters and the return type. In this case, there is no return type for this one, but down here there is. We return int. So all of these if I have a class, like we will have in just a moment, if any of them conform to some protocol that we've defined here. Then they have to, they are required to implement all of these properties and methods. And we can see that that's the case down in the sub class we have conformed to the sum protocol and if I were to remove any of these implemented methods or properties. Then I'll get a compiler error. And you can see the compiler, some type, some class does not conform to protocol. Some protocol. And so if we put that back, we will remove our compiler Now protocols can also be inherited and that's what we're doing here. So we take some protocol. And we create a new protocol definition, and we inherit the sum protocol. And the syntax is just like a class inherits another class. And we additionally put another method here so we are going to inherit all the base properties and methods from some protocol. And then, we can add whatever properties or methods we want to require Any type that is going to conform to implement. So here we have another class that then conforms to another protocol so this class is required to implement all of these properties and methods in the base protocol, and the additional method we added in another protocol. So you can see that here and if we removed [INAUDIBLE] Our newly added method then we get a compiler. If we remove out any of the base properties or methods, the same thing we'll get a compiler. And then the only last detail in this playground example is just. That classes derived from protocols behave just the same as any other class. We instantiate them and we use their methods and the keypoint though in this is that we are requiring certain methods to be on a class so that is something does communicate this. Some other components from other class communicates with these conformed types that they know they can call these methods in these properties every time, and there won't be some type of runtime error compiler. [MUSIC]
