Concealment design pattern in Swift

This article introduces a design pattern that I call Concealment, and demonstrates how to use the pattern in Swift code.


The Concealment pattern enables types to support novel, related functionality without adding nonessential members to their interface.


User-defined types can easily be overused in a codebase, giving more prominence to things than necessary. A common example is having a data model entity be involved with tangentially related concerns; such as validation checks, business rule processing, and display formatting. It is preferable to conceal the augmentation and usage of your types behind an API expressly built for a single responsibility, rather than expose those implementation details to all the types’ consumers.

Swift implementation advice

Create a new type that represents the task to be performed. In the new type’s file, add a private extension for each of your pre-existing types whose participation in the task is being concealed. Pass an instance of the new type into the private extension methods, as a form of context, if necessary.

Swift Tip: private type members can be accessed from anywhere in the same file.


This demo project is available on GitHub. It is an iOS app that converts text to Morse code and plays it out loud, inspired by a programming challenge described here.

The Morse code data model is simple, and I wanted it to stay this way.

The app converts the user’s text input into instances of this abstraction. It must then transform that abstraction into two consumable formats:

  1. A string filled with dots, dashes, and separators so that the user can view the message they typed in as Morse code.
  2. A sequence of on/off states with relative durations so that the Morse code message can be played to the user.

It can be tempting to add methods or properties to the data model types to support such transformations, but doing so would reduce the clarity and simplicity of the data model. Instead, let’s conceal the data model’s participation in these transformation tasks, treating their involvement in the task as a mere implementation detail.

Here is how an EncodedMessage is transformed to a string filled with Morse code dots and dashes.

Similarly, this is how the same EncodedMessage becomes a sequence of on/off states suitable for transmission (a.k.a. playback).

The MorseTransformation<T> struct is responsible for projecting a Morse encoded message into another format. However, as seen below, it merely contains the parameters for a transformation and passes itself to the data model, which does the heavy lifting.

Since all of the data model extensions are private, the rest of the codebase does not know about or have access to the methods added to support transformations. Usage of the data model to support this novel functionality is an implementation detail.

The Concealment pattern is only applicable in languages that support private type extensions, or something equivalent. Thanks to Swift’s thoughtful design, it is easy for Swift developers to apply this pattern and keep their types simple.

Posted in Swift | Tagged | 1 Comment

Analyzing a dependency graph in Swift

I published my solution to Dave Thomas’s Transitive Dependencies programming exercise, known as a kata, to GitHub:

The Challenge

This exercise involves analyzing a graph data structure which contains nodes that “depend on” other nodes. A graph is represented as direct dependencies between nodes:


The objective is to find all of a node’s dependencies, both direct and indirect, like so:


An interesting complication is that a graph might contain cyclical dependencies, where a node indirectly depends upon itself. A proper solution to this problem must be able to cope with a graph like this:


If this programming challenge interests you, stop reading now and solve the puzzle for yourself! Check out the kata for more information.

My Solution

My solution relies on three things:

  1. An instance of Swift’s Set<T> collection keeps track of which nodes have been visited.
  2. The higher-order function reduce accumulates nodes into a Set as they are visited.
  3. Recursion is used to visit dependencies from the reduce method’s combine logic.

Here’s how I solved this little puzzle:


You can download the Xcode project here.

Posted in Swift | Tagged , | 1 Comment

DRY Fusion data munging kata in Swift

I worked through one of Dave Thomas’s programming exercises, called a kata, and pushed my Swift 2.2 code to GitHub. The code shows how to apply the Don’t Repeat Yourself (DRY) principle to two similar but different data processing programs.


The end result of this exercise is a satisfyingly readable higher-order function, which is similar to a template method but does not require subclassing to supply context-specific logic.

Here is the kata:

And here is my implementation of the kata’s third challenge:

This was a great learning experience!

Posted in Swift | Tagged , | 1 Comment

Creating an iOS Wizard UI in Swift

I published a reusable framework, written in Swift, for implementing the Wizard UI design pattern, named Wizardry. It simplifies creating a user interface composed of multiple view controllers that enables the user to complete a task. This is a particularly important UI design pattern for mobile apps due to the small screen size.


Over the years I have built wizards for several applications, on various of platforms and with different languages. The design approach seen in Wizardry is the culmination of these efforts, with a simple, clean API that I hope developers find intuitive and complete.

Wizardry’s README file explains how to use it to build your own wizard. For a complete example, refer to the demo project.

Posted in Swift | Tagged ,

Stones on a beach

Suppose that you arrange stones into a spiral on a sandy beach.


After meticulously arranging your stone spiral, the world seems hell-bent on destroying it. A dog steps on some of the stones, a big wave carries some of them away, and a child throws part of your spiral into the ocean.

There are many ways to form a spiral with those stones; countless millions of arrangements that enable someone to perceive a spiral on the sand. However, there is an almost infinite number of ways to arrange those stones that do not form a spiral. The odds are overwhelmingly in favor of your creation losing its spiral-ness simply because there are so many more non-spiral arrangements.

Now suppose that each stone is a tiny piece of a computer program. Like the stones, the individual parts of a program are carefully arranged to induce an emergent phenomenon. Instead of a spiral emerging from stones and sand, features emerge from logic and state.

The unpredictable world in which we live indiscriminately nudges our creations toward chaos. Features break because of minute changes made to those tiny pieces of the program.

What can and should developers do to defend their creations against unceasing entropy?

Posted in Thoughts, Uncategorized | 8 Comments

Find keys by value in Swift dictionary

Here’s a helper method that might come in handy when working with a Swift dictionary. It finds every key mapped to a particular value.

This is similar to the allKeysForObject(_:) method of NSDictionary, but it is generic so it can return an array of properly types keys, instead of an array of AnyObject.

Posted in Swift | Tagged

Striving for excellence as a software developer

I’ve been a professional software developer for over a decade, and have been writing code since I was a kid. Over the years I have read a lot of advice from software developers with far more experience than me, to expand my thinking and perhaps avoid some mistakes that they once made. Some of my colleagues at various companies have been invaluable sources of insight, as well.  I’ve had enough experience at this point to learn more than a few lessons of my own, some the hard way. I want to give back, and share what I’ve learned with others.

There are basic common sense things about how to write good code that seem obvious once you know them, but are not so obvious to people who have not yet learned those lessons. Some excellent advice is repeated so often that it seems like a cliché to even mention (encapsulation is good!).

I increasingly appreciate the importance and benefits of my received wisdom very gradually. The more code I write and fix, year after year, the more these basic principles of software craftsmanship resonate with me (no seriously, encapsulation really is quite good!)

Many thoughts about what it means to write good code flutter around inside my head. In order to structure these thoughts into something coherent and meaningful I’ve started a living document on GitHub, titled “Sustainable Coding“.

Note: I strongly hesitated to use “sustainable” in the title because it is a popular buzzword. I generally consider the presence of buzzwords to be a warning that something lame is afoot. But, as I explain in the introductory section, it truly is the best word I can find that fits my needs.

If you’re interested in reading my take on what it means to strive for excellence as a software developer, here’s the link:

This document is a work-in-progress. There’s a lot more that I want to write about, but I’m not in a rush. The document will grow at its own pace.

Posted in Sustainable Coding | 4 Comments