The Difference between Entity and Value Object, and How They Relate to Swift's Identifiable and Equatable Protocols
Helge Heß recently posted on Mastodon that he “still find[s] it disturbing how many #SwiftLang devs implement Equatable
as something that breaks the Equatable contract, just to please some API requiring it. Feels like they usually should implement Identifiable
and build on top of that instead.”
Mutating Struct and State Observers: How the Latter Will Be Notified Even for 'No-Ops'
I may be 7 years late or so – but until last week, I didn’t realize that didSet
property observers would fire when the observed property hasn’t actually changed. All you need is a mutating func
that doesn’t even need to mutate. This can be illustrated with a simple piece of code:
Replacing More Reference Objects with Value Types
I was removing quite a few protocols and classes lately. Turns out, I like what’s left. I relied on classes for example because they can be subclassed as mocks in tests. Protocols provide a similar flexibility. But over the last 2 years, the behavior I was testing shrunk to simple value transformations.
Better Form Model Validation
Earlier this month, I wrote about validating temporary models for forms. The validation returned .complete
or .incomplete
, which doesn’t help much when you want to show what did go wrong. So I came up with a richer validation syntax.
Validate Temporary Form Models
Ian Keen posted an article about type-safe temporary models. You would use them like scratch pad contexts in Core Data: in forms, you collect information into these temporary models and then generate your real objects from them.
Configuration Objects and the Then Microframework
When parameter lists grow or two kinds of parameters seem to go together a lot, it’s time use the extract parameter object refactoring for greater good – then you can even specify sensible defaults.
This is a typical way to pass a set of options to an objects during initialization in a language like Swift. In languages like JavaScript or Ruby, dictionaries of key–value pairs can work just as well. Using dictionaries in Swift for this can be a pain, though.
Now Soroush wrote about a way that uses the Then microframework as a replacement for configuaration dictionaries. This way you don’t have to promote every property to the initializer’s list of parameters. Here’s a before and after, where you can see that without then
you have to write a lot of repeating boilerplate:
// Before
struct FieldData {
let title: String
let placeholder: String
let keyboardType: UIKeyboardType
let secureEntry: Bool
let autocorrectType: UITextAutocorrectionType
let autocapitalizationType: UITextAutocapitalizationType
init(title: String,
placeholder: String = "",
keyboardType: UIKeyboardType = .Default,
secureEntry: Bool = false,
autocorrectType: UITextAutocorrectionType = .None,
autocapitalizationType: UITextAutocapitalizationType = .None)
{
self.title = title
self.placeholder = placeholder
self.keyboardType = keyboardType
self.secureEntry = secureEntry
self.autocorrectType = autocorrectType
self.autocapitalizationType = autocapitalizationType
}
}
let fieldData = FieldData(title: "Password", secureEntry: true)
Now with then
, making non-mandatory properties mutable and getting rid of the boilerplate:
// After
struct FieldData {
let title: String
var placeholder = ""
var keyboardType = UIKeyboardType.Default
var secureEntry = false
var autocorrectType = UITextAutocorrectionType.No
var autocapitalizationType = UITextAutocapitalizationType.None
init(title: String) {
self.title = title
}
}
let fieldData = FieldData(title: "Password").then({
$0.secureEntry = true
})
That’s a Swift alternative to Ruby’s hash-based option initializers. There, the dictionary’s key is used as the setter’s name which is then invoked like so:
class Example
attr_reader :name, :age
def initialize(args)
args.each do |k,v|
instance_variable_set("@#{k}", v) unless v.nil?
end
end
end
e1 = Example.new :name => 'foo', :age => 33
#=> #<Example:0x3f9a1c @name="foo", @age=33>
Always Write Functions to Cope with all Possible Parameter Values
Matt Galagher is back writing at Cocoa with Love. His goal is maintainability, which is the greatest of all, I think. It’s easy to copy code samples together to create an app, bur it’s hard to create a product you can keep alive and make better over years. In that vein, his first article, “Partial functions in Swift, Part 1: Avoidance”, includes a lot of details why partial functions will hurt you. This is a great topic. Read his post for the basic set theory involved.
Achieve More with a Variety of Value Objects in Swift

From the department of Domain-Driven Design code patterns, I today present to you: well-named value objects! You can go a lot farther than you have previously imagined with value objects in Swift. Now that Swift is more than a year old, most of us have seen the use of struct
and heard how useful passing objects by value is.