Swift 4 Protocol-Oriented Programming

In object-oriented programming, we cannot create an object without a blueprint that tells the application what properties and methods to expect from the object. In most object-oriented languages, this blueprint comes in the form of a class.

Access controls allow us to restrict the access to, and visibility of, parts of our code. This allows us to hide implementation details and only expose the interfaces we want the external code to access.

In Swift, a tuple is a finite, ordered, comma-separated list of elements. Tuples are one of the most underutilized types in Swift and, let’s look at them in detail. 

There are some very fundamental differences between value types (structures, enumerations, and tuples) and reference types (classes). The primary difference is how the instances of value and reference types are passed. 

A recursive data type is a type that contains other values of the same type as a property for the type. Recursive data types are used when we want to define dynamic data structures, such as lists and trees. 

The process of choosing which implementation to call is performed at runtime and is known as dynamic dispatch. Let’s explore dynamic dispatch in this video. 

An extension is defined by using the extension keyword followed by the name of the type you are extending. We then put the functionality that we are adding to the type between curly brackets. 

Protocols, like other types, can be extended. Protocol extensions can be used to provide common functionality to all types that conform to a particular protocol. This gives us the ability to add functionality to any type that conforms to a protocol rather than adding the functionality to each individual type or through a global function. 

In numerous apps, across multiple platforms, we are often asked to validate user input either after the user has entered it. This validation can be done very easily with regular expressions; however, we do not want various regular expression strings littered throughout our code. We can solve this problem by creating different classes or structures that contain the validation code. 

Let's say that, in our application, we needed to calculate the factorial of some integers. A factorial is written as 5! To calculate a factorial, we take the product of all the positive integers that are less than or equal to the number. Take a look at how we do that with extensions. 

In this video, we will show how we can conform to the Equatable protocol using extensions. When a type conforms to the Equatable protocol, we can use the equal-to (==) operator to compare for equality and the not-equal-to (! =) operator to compare for inequality. 

To fully understand generics, we need to understand the problem that they are designed to solve. 

A generic type is a class, structure, or enumeration that can work with any type, just like Swift arrays and optionals can work with any type.

An associated type declares a placeholder name that can be used instead of a type within a protocol. The actual type to be used is not specified until the protocol itself is adopted. 

Prior to Swift version 4, we could use generics with subscripts only if the generic was defined in the containing type, however we were unable to define a new generic type within the subscript definition. 

Apple has implemented the COW feature for all the data structures (Array, Dictionary, and Set) within the Swift standard library. With COW, Swift does not make a second copy of the data structure until a change is made to that data structure. 

Now that we have seen how to use generics, let's see how we can use them in a protocol-oriented design. 

Swift provides full support for developing applications in an object-oriented way. Prior to Swift 2, Swift is primarily an object-oriented language in the same way as Java and C#. Here, we will be designing the vehicle types in an object-oriented way and looking at the advantages and the disadvantages of this design.

Two of the issues that we saw with the object-oriented design were directly related to each other, and are the result of Swift being a single-inheritance language. Remember a single-inheritance language is a language that limits a class to having not more than one superclass. An object-oriented design with a single-inheritance language, such as Swift, can lead to bloated superclasses because we may need to include functionality that is needed by only a few of the subclasses. This leads to the second issue related to Swift being a single-inheritance language, which is the inheritance of functionality that a type does not need. 

Now that we know the object-oriented design, let's look at how we could design the vehicles in a protocol-oriented way. 

In the object-oriented programming example, we created a Vehicle superclass from which all the vehicle classes were derived from. In the protocol-oriented programming example, we used a combination of protocols and protocol extensions to achieve the same result; however, there are several advantages to the protocol-oriented design. 

Creational patterns are design patterns that deal with how an object is created. There are two basic ideas behind creational patterns. The first is encapsulating the knowledge of which concrete types should be created and the second is hiding how instances of these types are created. 

Structural design patterns describe how types can be combined to form larger structures. These larger structures can generally be easier to work with and hide a lot of the complexity of the individual types.

Behavioral design patterns explain how types interact with each other. These patterns describe how different instances of types send messages to each other to make something happen. 

Logging frameworks make it incredibly effortless to turn on log messages which makes debugging very easy while the application is being developed. These debugging messages can then be turned off when it is time to build the production release of the application. To do this, these logging frameworks let us define how and where we wish to log the messages for predefined log levels. 

he most serious applications need to persist some amounts of data. This data could be transactional data, user preferences, or the current state of the application. There are many ways that data can be persisted in our applications. Let’s see how we choose the correct way.