Designing Dependencies: Reachability

Episode #112 • Aug 10, 2020 • Subscriber-Only

It’s straightforward to design the dependency for interacting with an API client, but sadly most dependencies we work with are not so simple. So let’s consider a far more complicated dependency. One that is long living, and involves extra types that we can’t even construct ourselves.

Introducing a long-living dependency
Controlling a long-living dependency
Controlling a model you can't construct
Mocking a long-living dependency
Improving a dependency's interface
Using the streamlined dependency
Next time: controlling Core Location

Unlock This Episode

Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.


And now everything builds, albeit a little slowly because our live implementation is purposely taking a long time to build. The WeatherFeature framework builds instantly, and this means we can rapidly iterate on it, even on a clean build.

The SPM linker gotchas were definitely a pain, but we were luckily able to work through them. In the future Xcode will hopefully make everything a bit more streamlined here and take care of these kinds of linker issues automatically.

But let’s stop to appreciate what we’ve done here because this is really powerful. We are getting a ton of benefits all at once just by properly designing this dependency.

  • First we are able to load up our screen in many different states and edge cases, such as when the API returns no data, or some data, or a failure, and even when the request just takes a long time to finish.
  • And the mere fact that we can control the dependency in this way means this feature will be easy to test. We haven’t done that yet, but we will do that soon.
  • And last, by pushing ourselves to properly control and separate the dependency from our application code we opened ourselves up to some nice compile time optimizations. We can now build features in isolation without building their dependencies. The only time we need to actually build a live dependency, whether it be Alamofire, Starscream, or some huge shared C++ library, is when building the full app that will actually run in the simulator or on your device.

So, there is a lot of power in extracting a dependency from application code and separating its interface from its implementation. I think a lot of people would assume that the only way to do this is to use protocols, but that’s just not true. You can do it just as easily using plain, concrete data types, and there’s even a few perks to doing it in this style.

This episode is for subscribers only.

Subscribe to Point-Free

Access this episode, plus all past and future episodes when you become a subscriber.

See plans and pricing

Already a subscriber? Log in


Protocol-Oriented Programming in Swift

Apple • Tuesday Jun 16, 2015

Apple’s eponymous WWDC talk on protocol-oriented programming:

At the heart of Swift’s design are two incredibly powerful ideas: protocol-oriented programming and first class value semantics. Each of these concepts benefit predictability, performance, and productivity, but together they can change the way we think about programming. Find out how you can apply these ideas to improve the code you write.

Collection: Protocol Witnesses

Brandon Williams & Stephen Celis

Protocols are great! We love them, you probably love them, and Apple certainly loves them! However, they aren’t without their drawbacks. There are many times that using protocols can become cumbersome, such as when using associated types, and there are some things that are just impossible to do using protocols. We will explore some alternatives to protocols that allow us to solve some of these problems, and open up whole new worlds of composability that were previously impossible to see.