Swift: Caveats for Structs as Data Models
Not quite the promised land …but almost!
It’s great to see Objective-C veterans get excited about new things and new ways of thinking when it comes to the Swift language. As developers, we should always be extending our skills and be willing to change our mentality towards paradigms as new things come to be.
One such thing was the idea to embrace immutability within our data objects, which is a great idea and totally should be adopted. Another such thing was to move our data models to structs, which sounded great in theory but when it came to implementation, created a world of pain for a lot of people who decided to go all in.
Don’t get me wrong, data models as structs give credence to some really great benefits. But it’s not all rainbows, smiles and Pepsi cola. In this post I’ll detail some of the caveats you will encounter when moving your data models from classes to structs.
Objective-C
If you’re project’s codebase is shared between both Swift and Objective-C, you will find that Objective-C code cannot interface with Swift’s structs. Because to use Swift code, objects need to inherit from NSObject.
Structs are not friends with Objective-C
Inheritance
One of the four main pillars of object-orientated programming, something so deeply ingrained in our thinking. Why repeat code when we can just use inheritance? One thing I like to do is make my data model’s inheritable so I don’t have to repeat JSON parsing code for objects that share an abstract data model, it also keeps my models uniform.
Structs cannot inherit from each other.
UserDefaults
It’s pretty safe to say that we’re all (at some point) guilty of storing data inside UserDefaults. Such an act is perfectly fine, because not everyone wants to deal with CoreData for persistantly storing just a few objects. Technically this is possible, but there are a few hoops to jump through to get it working. Thus you may have well have just used a class instead.
Structs cannot be serialized into an NSData object
Strengths of a struct
I don’t want you to think I’m just bashing on structs because they once hurt my feels. There are plenty of upsides to using structs over classes for your data models. Value types are a powerful thing:
Safety
Because structs are passed around by value type, they don’t have reference counts.
Memory
Because they don’t have reference counts, they can’t get caught up in a reference cycle memory leaks.
Speed
Value types generally get allocated on the stack instead of the heap. So they’re a lot faster than classes, and I mean a lot. This one post on Stack Overflow benchmarked a struct operation’s performance to be > 900 times faster than a class doing the exact same thing.
Copying
Ever tried to copy an object back in Objective-C? You’d have to do a defensible copy, which was always annoying because each time you try, you’d forget how you did it the last time. Value types copy with ease!
Thread-safe
Value types are automagically thread safe. Doesn’t matter which thread you access your struct from. Ain’t no thang.
Conclusion
So there you have it, I’ve laid at the cons and even threw in some pro’s to help you way out your decision on whether or not you should adopt struct types for your data models.
However, there’s no reason why you cant mix and match between the two. In my own projects I like to use structs for the smaller models that I don’t intend to be inherited, stored in UserDefaults or used with Objective-C.
If you like what you’ve read today you can check our my other articles or want to get in touch, please send me a tweet or follow me on Twitter, it really makes my day. I also organise Playgrounds Conference in Melbourne, Australia and would to see you at the next event.
