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.
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
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.
It’s pretty safe to say that we’re all (at some point) guilty of storing data inside NSUserDefaults. 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:
Because structs are passed around by value type, they don’t have reference counts.
Because they don’t have reference counts, they can’t get caught up in a reference cycle memory leaks.
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.
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!
Value types are automagically thread safe. Doesn’t matter which thread you access your struct from. Ain’t no thang.
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 NSUserDefaults or used with Objective-C.