Swift 3, Protocol-Oriented Programming

My new book, Swift 3 Protocol Oriented Programming has been released.  I wrote the original Protocol Oriented Programming book when Swift 2 was released and since then a lot has changed with the language.  This new book is a major rewrite and includes an additional chapter on generics.  The following gives an overview of each chapter:

Chapter 1, Object-Oriented Programming vs Protocol-Oriented Programming, This chapter will show the differences between object-oriented programming and protocol-oriented programming giving the reader a good understanding of the difference paradigms.  By the end of the chapter the reader should have a basic understanding of protocol-oriented programming and what it offers.

Chapter 2, Our Type Choices, In this chapter we will look at the different types that Swift offers (Structs, Classes, Enums and Tuples).  We will show several examples of when to use the various types and when not too.

Chapter 3, Catching our Errors, This chapter will look at the various ways that we can catch and report errors.  This chapter will not only cover the new Swift 2 do-try-catch blocks but also the older error catching patterns

Chapter 4, It’s all about the Protocol, This chapter will be all about the protocol.  We will show the advantages of using protocols and why, in our design, we should always think about the protocol first and the actual types that conform to the protocol second.

Chapter 5, Lets extend some types, This chapter will cover extensions in great detail.  We will look at how to extend standard Swift types like structures and classes.  We will also look at protocol extensions and discuss why they are so important to Protocol-Oriented programming.

Chapter 6, Working with Generics, This chapter will cover generics.  We will look at how we generics can be used with the protocol-oriented programming paradigm to write flexible and reusable code.

Chapter 7, Design Patterns with Protocol-Oriented programming, We will be implementing several design patterns using protocol-oriented programming.  For each of the design patterns we will look at the problem they are designed to solve and how to implement the pattern.

Chapter 8, Case Studies, In this chapter we will explore three case studies.  This chapter is designed to pull everything from the first six chapters together to show the reader how to use Protocol-Oriented programming is real world situations.

This book will guide you through every aspect of protocol-oriented programming to help you take advantage of it in your applications.  You can purchase a copy of the book on Amazon.

Mastering Swift 3

Mastering Swift 3 has been released

I wrote the original Mastering Swift book in 2015 and have updated it for each major release of the Swift language.  Today I would like to announce the release of my new book titled Mastering Swift 3.  Mastering Swift 3 has been updated to reflex the changes in Swift with the third release of the language.  You can purchase the book from Amazon.

The following gives an overview of what is covered in Mastering Swift 3:

Chapter 1, Taking the First Steps with Swift, will introduce you to the Swift programming language and discuss what inspired Apple to create Swift. We'll also go over the basic syntax of Swift and how to use Playgrounds to experiment and test Swift code.

Chapter 2, Learning about Variables, Constants, Strings, and Operators, will introduce you to variables and constants in Swift and when to use them. There will be brief overviews of the most common variable types with examples on how to use them. We'll conclude this chapter by showing examples of how to use the most common operators in the Swift language.

Chapter 3, Using Collections and the Tuple type, will explain Swift's array, set, and dictionary collection types and show examples on how to use them. We'll also show how to use the Tuple type in Swift.

Chapter 4, Control Flow and Functions, will show you how to use Swift's control flow statements. These include loops, conditional, and control transfer statements. The second half of the chapter is all about functions.

Chapter 5, Classes and Structures, is dedicated to Swift's classes and structures. We'll look at what makes them similar and what makes them different. We'll also look at access controls. We'll close this chapter out by looking at memory management in Swift so you will understand how ARC works and how to avoid Strong Reference Cycles.

Chapter 6, Using Protocols and Protocol Extensions, will cover both protocols and protocol extensions in detail since protocols are very important to the Swift language, and having a solid understanding of them will help us write flexible and reusable code.

Chapter 7, Protocol Oriented Design, will cover the best practices of Protocol Oriented Design with Swift.  It will be a brief overview of what is covered in my POP book (which will soon be updated for Swift 3).

Chapter 8, Writing Safer Code with Availability and Error Handling, will cover error handling in depth as well as the new availability feature.

Chapter 9, Custom Subscripting, will discuss how we can use custom subscripts in our classes, structures, and enumerations. Subscripts in Swift can be used to access elements in a collection. We can also define custom subscripts for our classes, structures, and enumerations.

Chapter 10, Using Optional Types, will explain what optional types really are, what are the various ways to unwrap them, and optional chaining. For a developer who is just learning Swift, optional types can be one of the more confusing items to learn.

Chapter 11, Working with Generics, will explain how Swift implements generics. Generics allow us to write very flexible and reusable code that avoids duplication.

Chapter 12, Working with Closures, will teach us how to define and use closures in our code. Closures in Swift are similar to blocks in Objective-C except that they have a much cleaner and easier way of using syntax.

Chapter 13, Using Mix and Match, will explain mix and match and demonstrate how we can include Swift code in our Objective-C projects and Objective-C code in our Swift projects. With all of the apps and frameworks written in Objective-C, it was important to allow Swift and Objective-C code to work together.

Chapter 14, Concurrency and Parallelism in Swift, will show how to use both Grand Central Dispatch and Operation Queues to add concurrency and parallelism to our applications. Understanding and knowing how to add concurrency and parallelism to our apps can significantly enhance the user experience.

Chapter 15, Swift Formatting and Style Guide, will define a style guide for the Swift language that can be used as a template for enterprise developers who need to create a style guide since most enterprises have style guides for the various languages that they develop in.

Chapter 16, Swift Core Library, will explore some of the functionality in the Swift core library.  This will include accessing REST services, working with JSON data and the formatting framework. 

Chapter 17, Adopting Design Patterns in Swift, will show you how to implement some of the more common design patterns in Swift. A design pattern identifies a common software development problem and provides a strategy for dealing with it.

If you are new to the Swift programming language and looking for a book to teach you the basics of the language or an intermediate level developer that is looking for a book to teach you some of the advance topics of the language then Mastering Swift 3 may be the book you are looking for.  You can purchase the book from Amazon.

Swift and the Beaglebone Black – Better together with SwiftyBones

SwiftyBones is a modular Swift library for interacting with both the digital GPIO and Analog pins on the BeagleBone Black.  This library is written to make it easy to write Swift applications that run on the Beaglebone Black that interacts with external sensors, LED or any device connected to the Digital GPIO and/or Analog pins.  

Since SwiftyBones is a modular library you only need to include the functionality required for your projects rather than all of the functionality.  Currently SwiftyBones supports both digital GPIO and Analog however I need to add PWM support soon for my robotics projects that my daughter and I want to work on this summer so you should hopefully see it supported soon as well.

SwiftyBones comes with a script called swiftybuild.sh that will help you build swift projects with multiple files.  This script comes in very handy since SwiftyBones itself contains multiple files.  

There are several example projects (with Fritzing diagrams) included with SwiftyBones to help you get started using Swift and SwiftyBones with your next IoT, Robotic or any other project you are working on with the Beaglebone Black.

Please feel free to send me any suggestions that you may have for this project.  Also please feel free to contribute code especially if you know how to get PWM working with the 4.1+ kernel.

What is Protocol Oriented Programming to me?

I have had numerous conversations about what exactly is Protocol Oriented Programming since my Protocol Oriented Programming with Swift book was released.   Everyone I spoke to seemed to have his or her own opinion about what POP is.  Out of all of those conversations I think this is the best explanation that I heard “Programming with an orientation toward the use of protocols for abstraction”. 

So what do we mean when we say that POP is “Programming with an orientation toward the use of protocols for abstraction”?  Quite simply my interpretation of this is with POP we should be programming to a protocol and not to an implementation.  This is very similar to other languages where we use interfaces however Protocols in Swift take a more predominate role within the language itself where as other languages, like C# and Java, the interface really takes a back seat to the class hierarchy.

In my POP vs OOP post I demonstrated a lot more than just the protocol so you may be asking yourself what are all of the other features that I talked about.  This is very similar to saying that Object Oriented programing is based on the concept of programming with objects.  Now we all know that good OOP design is about a lot more than just the object, similarly good POP design is about more than just the protocol which is why I think Apple introduced Protocol Extensions during their POP presentation (I could be wrong about and it is just my opinion).

So what makes for a good POP design?  The post that I wrote that compared OOP to POP  really showed what I think is good POP design.  You could also pick up my Protocol OrientedProgramming with Swift book on the subject as well :).  In this post rather than going in depth in to POP design I would like to touch on a couple of points that people have brought up to me based on my book and earlier post.

Protocol Extensions are simply syntactic sugar

When people say that Protocol extensions are simply syntactic sugar they are absolutely correct however there is nothing wrong with syntactic sugar.  There are other ways that we can avoid duplicate code when using value types however protocol extensions are very convenient and also gives us good code organization however for good code organization we do want to avoid having multiple extensions for a single protocol or type.  For example we should avoid this unless each extension has different constraints defined.

protocol Foo {

    var x: Int {get set}

}

extension Foo {

    func add(y: Int) -> Int {

        return x + y

    }

}

extension Foo {

    func sub(y: Int) -> Int {

        return x - y

    }

}

Use Protocol Extensions with caution and use constraints where necessary

It is very ease to simply add a protocol extension without thinking too much about the types that conform to the protocol.  For example in my POP book I used the following example of how to extend the CollectionType protocol.  I then followed it  up in my book up by pointing out how this extension does not work for all types that conform to the CollectionType protocol like the Dictionary type therefore we either needed to use a constraint to limit the implementations that received this functionality or only extend the specific implementation that needs this functionality..

extension CollectionType {

    func evenElements() -> [Generator.Element] {

       

        var index = self.startIndex

        var result: [Generator.Element] = []

        var i = 0

        repeat {

            if i % 2 == 0 {

                result.append(self[index])

            }

            index = index.successor()

            i += 1

        } while (index != self.endIndex)

       

        return result

    }

   

    func shuffle() -> [Self.Generator.Element] {

        return sort(){ left, right in

            return arc4random() < arc4random()

        }

    }

}

Avoid getting to granular with your protocols

To me, making smaller more specific protocols and using protocol inheritance and composition as I illustrated in my POP vs OOP post is an advantage that POP design has over OOP design however it was pointed out to me by a very smart person that we need to avoid getting to granular with our protocol designs.  In OOP we have the problem where we get large monolithic super classes and sometimes this can not be avoided however with POP we as programmers and architects need to avoid making our protocols to granular.  The following code illustrates what we want to avoid.

protocol FooAdd {

    func add(x: Int, y: Int) -> Int

}

protocol FooSub {

    func sub(x: Int, y: Int) -> Int

}

protocol FooMul {

    func mul(x:Int, y: Int) -> Int

}

struct Bar1: FooAdd, FooSub, FooMul {

    func add(x: Int, y: Int) -> Int {

        return x + y

    }

    func sub(x: Int, y: Int) -> Int {

        return x - y

    }

    func mul(x:Int, y: Int) -> Int {

        return x * y

    }

}

In this example, FooAdd, FooSub and FooMul protocols only contain one function each and those functions are related (mathematical operation) therefore it really makes since to put them into a single protocol.  If you have multiple protocols that you are always grouping together, you may want to consider combining them into a single protocol. 

Error Handling in POP

In my Protocol Oriented programming with Swift book, I have a chapter on error handling.  I have been questioned about this since error handling is really part of the language itself and not really part of the POP paradigm.  These people are absolutely 100% correct however anytime we write or design an application we need to worry about how we will respond to and recover from errors therefore to me error-handling needs to be a part of any good design.  With this in mind, in my opinion, a book that talks about design, with a specific language, should include something on error handling.  That really is just my opinion and hopefully explains why I included a chapter on error handling in my book.

My Books and Posts

I received a one star review of my Protocol Oriented Programming with Swift book with a comment about my writing style.  Another person responded to the comment saying “The writing style in this book is actually very good. It is written so even the non-programmer can understand and grasp the concepts behind POP.”  That is really my goal not only in my books but also in this blog.  I try to write in a way that everyone can grasp the concepts discussed.  My favorite review that I have received for any of my books was one for my Mastering Swift 2 book where the reviewer said, “This book is simple enough my 13 years old has started reading it and while I do not anticipate him reading past chapter 12...it is easy enough for him to follow.”  I hope that I will always continue that writing style.

You see to me programming is something that is fun and magical.  I still remember the feeling I had as a 13 year old kid and writing my first Brickout game on a Commodore VIC-20.  Programming does not need to be overly complicated however we do need to ensure that our code works properly and can be easily maintained.  I really hope my posts and my books have helped.