My original article — “Best Practices for Building Swift Classes” — was published on appcoda.com.
In this tutorial, I’m going to show you some best practices that will help you design and implement classes (reference types) and then safely leverage reference semantics in Swift. Protocol-oriented programming (POP) and value semantics are all the rage now, but a promising new technology doesn’t mean you should throw all your classes away. Why not add some simple constructs to your classes like copy initializers, default initializers, designated initializers, failable initializers, deinitializers, and conformance to the
Equatable protocol? To get real about my sample code, I’ll adopt these constructs in some classes and show you my best practices working in real life for drawing in your iOS app interfaces.
I’ll walk through the process of creating several protocols, creating classes that adopt those protocols, implement inheritance in these classes, and use instances of the classes (objects), all to illustrate my best practices — and to show some of the extra steps you may have to go through when working with classes.
Continue reading “Some best practices for designing and coding Swift classes”
Those of you who’ve used Objective-C and Swift for any meaningful length of time must be familiar with the
self property of structs and classes. I’m not sure how many are aware of the
Self “type” (sometimes called a “requirement”). I would be very interested in knowing how many understand the difference between
Self. I’m talking about
self with lower-case “s,” which I’ll call “small self” herein. It’s pretty well documented. Similarly,
Self with an upper-case “S,” is what I’ll call “tall self” herein. It’s not very well documented.
Continue reading “Self versus self in Swift 4 – capital “S” and lowercase “s””
Notice that Swift almost seems to frown on making a copy of a reference type, i.e., a copy of an instance of a class, or, as some would rather put it, getting a copy of an object. I’m not talking about getting another reference to a class, I’m talking about getting an entire, separate copy of a class instance. This frowning on class copying is not an accident. Swift’s language architects want the syntax and semantics of the language to be crystal clear. They want developers to be confident that reference types and value types will both have 1) distinct and obvious meanings and that both types will 2) behave consistently. But still, why not be able to safely make a copy of a class instance? I’ll show you how in this tutorial by borrowing the copy constructor concept from C++. In Swift, we’d call this a “copy initializer.” (NOTE: Yeah, yeah, yeah, I know about
NSCopying in Cocoa and Objective-C.)
Continue reading “Class copy constructors in Swift 4 for defensive copying”
The code shown herein will only compile and link in Xcode 10 beta and run on iOS 12 beta and/or OS X 10.14 beta.
While working on a Swift protocol-oriented and generic linked list, I got to thinking about Apple’s “improvements” to version 4.2 of their flagship language. Since a linked list is a list, I thought, “Why not add a subscript to my linked list to facilitate finding specific nodes in my list?” I did that in Swift 4.1 and got what most developers would’ve expected, e.g., used
linkedList["node4"] to get the node in the list associated with the keyword “node4.” With Swift 4.2, I can use the controversial new
@dynamicMemberLookup language attribute and implement dot/member notation, like
Continue reading “Swift 4.2 improvements? Member/dot syntax for subscripts. Trying it out in a protocol-oriented, generic linked list.”
The code shown herein will only compile and link in Xcode 10 beta and run in iOS 12 beta and/or OS X 10.14 beta.
We’re in the middle of Apple’s annual product upgrade cycle and this article is the first in a series of tutorials meant to highlight the most important new features of Swift 4.2. Instead of trying to cover all of the 4.2 features/improvements in one very long article, I’m going go talk about each aspect of the new 4.2 version, one or two features at a time. (If you’re interested in more details as to why I’m focused on 4.2, see section “Swift version methodology” below.) Today, I’ll cover the
allSatisfy(_:) instance method (see also here) of the
Sequence protocol (see also here), of course intimately related to the
Collection protocol (see also here).
Continue reading “Swift 4.2 improvements to Collection and Sequence protocols with method allSatisfy”
The original article – Protocol Oriented Programming in Swift: Is it better than Object Oriented Programming? – was published on appcoda.com.
We’re going to talk in-depth about protocol-oriented programming (POP) using Swift 4 in this article. This post is the second and final article in a two part series. If you haven’t read the first, introductory article, please do so before continuing onwards. Today, we’ll: discuss why Swift is considered a “protocol-oriented” language, compare POP and object-oriented programming (OOP), compare value semantics and reference semantics, consider local reasoning, implement delegation with protocols, use protocols as types, use protocol polymorphism, review my real-world POP Swift code, and finally, discuss why I’ve not bought 100% into POP. Download the source code from the article so you can follow along: There are 2 playgrounds and one project on GitHub, both in Xcode 9 format and written in Swift 4.
Continue reading “Protocol Oriented Programming in Swift: Advanced Applications”
My original article — Protocol Oriented Programming in Swift: An Introduction — was published on appcoda.com.
(The second and final installment of this series is now available.)
The greatest enemy of software developers is complexity, so when I hear about new technologies promising to help me manage chaos, I listen. One of the “hot” methodologies generating much attention recently (at least since 2015) is “protocol-oriented programming” (POP) in Swift. We’ll use Swift 4 herein. While writing my own code, I’ve found POP to be promising. What’s very intriguing is Apple’s assertion that “at its heart, Swift is protocol-oriented.” I’d like to share my experiences with POP in a formal presentation, a clear and concise tutorial on this up-and-coming technology. I’ll explain the key concepts, provide plenty of code samples, make the inevitable comparison between POP and object-oriented programming (OOP), and pour cold water on the fad-oriented programming (FOP?) crowds’ claim that POP is a magic bullet solution to everything.
Continue reading “Protocol Oriented Programming in Swift: An Introduction”
We’re going to learn about a feature of Swift called “property observers” that help developers manage app state. You can easily add code to monitor changes to Swift native type property values as well as your own custom type property values. Remember that you can gain insight into an application by looking at its state: the data values stored in all properties of the app at a specific point in time. Getting a grip on app state, therefore managing complexity, is one of the biggest challenges in computer science. Property observers are one technology that help you get a grip. In today’s article, I’ll explain this Swift feature, demonstrate its usage with runnable examples of Swift code, show you how I built an app which relies on property observers, and provide you a list of other Swift technologies that help you manage app state and complexity. Here’s my sample app in action:
Download the Xcode 9 project and playground, both written in Swift 4, from GitHub so you can follow along with my discussion.
Continue reading “Swift 4 property observers: responding to changes in property values and managing state”