Protocols are, without a doubt, a major part of Swift’s overall design. However, they also come with their own set of downsides and trade-offs. This week, let’s take a look at some of those characteristics, and explore a few alternative ways of abstracting code in Swift — to see how they compare to using protocols.
Protocols continue to be an integral part of Swift, both in terms of how the language itself is designed, and also in how the standard library is structured. This week, let's take a look at how we can use protocols to create multiple levels of abstraction, and increasingly specialize them to become more and more specific to each use case.
This week, let's take a look at Swift 4.1's new Conditional Conformances feature, and how it enables us to design code in a much more recursive fashion, making it more flexible while also reducing duplication. We'll take a look at both a simple and more advanced example, and how the standard library uses this new feature.
Separation of concerns is a core principle when it comes to designing architectures and systems. However, even though it's a principle most programmers learn about early in their career, it's not always easy to apply in practice. This week, let's take a look at how to more easily separate the concerns of various types in Swift, using protocols.
An important part of maintaining any app, framework, or system is dealing with legacy code. This week, let's take a look at a technique for dealing with legacy code that lets us replace a problematic system class-by-class, rather than having to do it all at once.