[MUSIC] Now, what we want to do here is the whole point of using these common, clear interfaces is that now we have two data adaptors that we've created, a SQL server and an Oracle. And now we should, if for whatever reason our company changes and no longer we're a Microsoft company, but now we're an Oracle company. So it should be as simple as changing the data adapter type but the interfaces are the same, so there shouldn't be much recoding here. So, we're going to go ahead and change that to the Oracle DataSource and in fact, you can see that there were no compilers and because the Oracle DataSource Adapter require. It conform to the DataSource Protocol and had [COUGH] implemented all of these methods that we're using, and the functionality behaves exactly the same. It prints out, we had the Donald and Mickey records. And then, we update the Mickey record, we print those out, and functionally was the same. So now we're going to go and we're going to switch to a new playground, and we're going to show how we use a protocol as a type and the purpose behind that. Okay, so this playground, what we're doing is we're showing how we're going to use a protocol as a type and the advantage that that has. This is very similar to the data source playground that we used to just demonstrate Oracle and SQL server data sources. The only difference in this playground is that we've defined a data reader protocol right here. So rather than in our data source protocol that we previously defined. Rather than it Returning the read function here, requiring a read function that return an array of records. We're actually going to provide a new method called get reader and its going to require the data reader protocol as a type. And what that allows us to do is to have, to require at the, at when we implement a class. When we conform, when a class conforms to our data source protocol or some protocol. We can also have as input methods to maybe input parameters to a method, we can have. A protocol for that type to be passed in. So classes that are going to be passed into that method parameter they will have to conform to some protocol. In our case it's an output, it's a return type. And so we're saying that we can return A class that conforms to, in our case, the data reader protocol and requires certain properties and methods on that classes. So, it allows us to kind of branch this idea out of requiring certain interfaces, not only in our main class where we're conforming to a protocol, but to the different types, and the parameters, and the return types. We've created our DataReaderProtocol, and he's required to implement the read method that returns an array of records. And we go and create two new classes. The sql server data reader. So they these are going to be classes that conform to our data reader protocol. So we previously have these data source classes that conform to the data source protocol. But now, we also have this data reader protocol. And that's what we now we have a sequel server data reader, that conforms to the data reader protocol, and we have an Oracle data reader, and really we've just pushed for the sake of this demonstration. We've pushed in our existing read methods that were once down in our data source Section. Now we move them up into the data reader sections. And so, if you go look at, so we go ahead and we've implemented those. But if we look at our SQL Server data source that conforms to the data source protocol, they now are forced to create a getReader method. That returns the type DataReaderProtocol, and so we've made those implementations. And so SQL Server is obviously going to use the SqlServerDataReader. So it's going to create an instance of that, and return that here. And likewise, Oracle is going to Be required to implement the get reader method and return similarly a data reader protocol. But in it's implementation it's going to create a, it's going to instantiate an instance of an Oracle data reader where we implemented that both those up here the Oracle data reader and the SQL server data reader. So now when we look at the functionality here same thing they have now then when we go and use this datasources. The only change is that we have prior to iterating through our records we don't just get back. We don't just get back in array we actually have to get read her back, and then we can go ahead and call the read function which does return in array of records. And we have array to that we'll print out those records. And you can see that what's happening here. So again before update we have the Mickey Mouse phone number without the Mickey and then we add the. We update the nickeyRecord to include the NCKY ending and that appears here. Now if we go back again here and change this to OracleDataSource and the implementations are different the data reader implementation are different yet the functionality is the same because the interfaces are the same. Using protocols we were forced to define clear and known interfaces so that both implementations could be used the same. We're in the playground again and this is a quick note on mutating methods and protocol conformance. Here I have a protocol to find chapter protocol and below I have an enumeration of chapters, three cases one, two and three. And I conform to the chapter protocol. Now, if I were If it's important to know that if we do change on an enumeration type self that it has to be defined as a mutating function. You have to have the mutating keyword before a function and the protocol has to have the same keyword specified. So if I were to remove the mutating key word, then I get a compiler telling me that I'm not conforming correctly to the chapter protocol. So, that's our little note on. Mutating methods and protocol conformance. [MUSIC]
