Logo 61e73bc61c0e1780102320e879dc3cac0e29303ea8894dd8f10c942f3ba8120f

otters.io

An adorable little blog

Fighting the System (Design)

Wednesday — January 20th, 2016

I spend what seems like a majority of my time fighting anti-patterns. That work sucks. Writing code when I know exactly what it should do makes me happy. Whether it’s taking up someone else’s project or my own, bad system design is the worst problem to fight. You know that the work you are doing right now is difficult and that it could be exponentially easier if the work were applied in a different way.

The big battle right now in iOS development is the charge against Mega-Controllers. I am guilty of making Mega-Controllers. It’s so easy. Just make your views and then split your app logic into the ViewController. Need to share data? Put it in the App Delegate.

I can already hear the internet yelling:

“NO NO NO NO NO!”

  • The Internet

It’s quick, it’s dirty, and it’s easy. Maybe it’s good for a quick proof of concept, but it’s no fun for a large project. The big charge in the fast-and-loose world of Swift pre–3.0 is using Model, View, View-Model and Protocol Oriented Programming and I thought a quick and dirty overview could be helpful.

Model, View, View-Model, or MVVM as the cool internet kids say, is easily broken down by having your model, as you do. Be it your User, Recipe, or whatever data you’re dealing in, your model is pretty much the same as always. Your view is simply your storyboard, nibs, and other UIView code you have made that only have the data needed to set their labels, images, and what-nots. Instead of having a property that contains a model or setting up the view in the view controller you have a view model that handles the state of the view. Your View-Model is a fancy model that can configure your view as needed, so your View Controller only needs to set the view’s view model.

Protocol Oriented Programming, in Swift, uses protocols whenever logically possible instead of classes. This means that you are dealing with Value types instead of Reference types. This looks like fewer optionals in Swift unless explicitly needed which is handy dandy. I imagine this will spawn it’s own extreme anti-patterns in a few years but for now, it’s very hot.

I recommend Andy Matuschak’s NSSpain talk on refactoring the Mega-Controller to look further into these patterns.