Flyweight Design Pattern in iOS

Bart Simpson fly head from The Simpsons: Fly vs. Fly

The Flyweight is a structural design pattern which allows to reduce the memory usage of several objects which are sharing some properties or states that can be perfectly outside.

Implementation

First of all, it’s necessary to firstly understand the following two concepts, intrinsic and extrinsic states.

Intrinsic State

The intrinsic state is all object’s properties that are immutable, meaning these will not change over time, for example the birth date or nationality of a driver’s license user.

Extrinsic State

On the other hand, the extrinsic state is all mutable properties, meaning that these will change eventually, for example the expiration date or expedition place of a passport.

In order to implement this pattern, it is needed to identify the intrinsic and extrinsic states of an object in order to separate them.

For example, a institution or government dependency would have a record of all driver license and another dependency might have all passport information.

import Foundation

enum State: String { ... }
enum Nationality: String { ... }
enum BloodType: String { ... }

struct Address: Identifiable {
  let mainStreet: String
  let number: String
  let zipCode: String
  // ...
}

class DriverLincense {
  let nationalID: UUID
  let name: String
  let surname: String
  let birthDate: Date
  let nationality: Nationality
  let bloodType: BloodType
  var state: State
  var expedition: Date
  var expiration: Date
  var address: Address
  // ...
}

//... Another dependecy

enum StateCode: String { ... }

class PassportInfo {
  let passportID: UUID
  let nationalID: UUID
  let name: String
  let surname: String
  let birthDate: Date
  let birthPlace: String
  let nationality: Nationality
  let bloodType: BloodType
  var expedition: Date
  var expiration: Date
  var stateCode: StateCode
}

In this example, it is noticeable that some information might be repeated and could be extracted since it is not going to change, that’s called Intrinsic State.

// Intrinsic State
class PersonalInfo {
  let nationalID: UUID
  let name: String
  let surname: String
  let birthDate: Date
  let birthPlace: String
  let nationality: Nationality
  let bloodType: BloodType
}

By doing so, the actual types can point to a single Intrinsic State rather than have it twice in memory.

class DriverLincense {
  let personalInfo: PersonalInfo

  // Extrinsic State
  var state: State
  var expedition: Date
  var expiration: Date
  var address: Address
}

class PassportInfo {
  let personalInfo: PersonalInfo

  // Extrinsic State
  let stateCode: StateCode
  var expedition: Date
  var expiration: Date
}

On the second object, which contain another constant called stateCode, it was not considered intrinsic, event though it is not going to change, since it only belongs to the PassportInfo object context and it will be unnecessary to have on the DriverLicense object.

And now, those objects can share the same immutable state and save memory.

// Shared info
let myInfo = PersonalInfo( ... )

let myDriverLicense = DriverLicense(personalInfo: myInfo, ... )
let myPassportInfo = PassportInfo(personalInfo: myInfo, ... )

Take in mind this has to be a reference type since several objects will be pointing to the common state.

Advantages

This structural pattern is focused on saving resources when these are heavy to load at the same time and manage multiple instances of it.

• Saves memory usage. As it shares common state that will not mutate the memory usage lowers down.

Common mistakes

• Usage of multiple intrinsic states of the same object with the same properties and values. Avoid this by having a singleton or a flyweight factory which will make sure to have only one of each object.

Conclusion

This pattern becomes really useful when several objects that share common data will be loaded in memory and be process individually, for example a video game would need to load several objects to render them, but only the textures will be loaded once to save memory, and the references will be share on all instances that will display the object when needed.