TEAM LICENSES: Save money and learn new skills through a Hacking with Swift+ team license >>

Before and after: how to refactor your Swift code

Can the worst possible code ever get cleaned up? Apparently so!

Paul Hudson       @twostraws

Matt Gallagher has written a thoroughly brilliant piece showing off terrible application architecture and (more importantly) how to refactor it to be sensible. He starts with a scenario that you may already be painfully familiar with: no model separation, meaning that the data required for his app to work must be juggled between views and view controllers.

This in itself is sadly not uncommon, but to really drive his point home Gallagher ported some 20-year-old macOS code to an iOS app, to produce Mines for iOS – a Minesweeper clone that might look good enough to players, but was a festering vortex of appalling code underneath.

How bad? Well, to give you a taste:

Each of the SquareView objects (instances of UIButton) which represent the tiles in the game contains the following properties… This is not a cached representation of state store in another location, this is the only representation of the minefield, spread across the 100 different UIButton subclass instances used to display the minefield.

Now, anyone can write bad code – myself included! – but Gallagher's article is only just getting started, because his whole point is that even something this shocking can be refactored into a more modern, sensible layout. Even better, his GitHub repository provides before and after versions of the code so you can see for yourself what changed and why.

Towards the end the article discusses the whole point of separating your model, and that's where it gets really interesting:

Writing an application without a separated Model is considered the worst application design, not because it immediately leads to disaster but because it indicates that you’ve never tried to clearly isolate what your program does. We don’t write applications because we love constructing views and controllers – these are merely a means to an end. We write applications to present our Model, perform actions on it and view the results.

Link: The worst possible application

Hacking with Swift is sponsored by Superwall.

SPONSORED Superwall lets you build & test paywalls without shipping updates. Run experiments, offer sales, segment users, update locked features and more at the click of button. Best part? It's FREE for up to 250 conversions / mo and the Superwall team builds out 100% custom paywalls – free of charge.

Learn More

Sponsor Hacking with Swift and reach the world's largest Swift community!

Buy Pro Swift Buy Pro SwiftUI Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Beyond Code

Was this page useful? Let us know!

Average rating: 5.0/5

Unknown user

You are not logged in

Log in or create account

Link copied to your pasteboard.