Design Patterns｜Practical Solutions for Socket.IO Client Library Challenges

点击这里查看本文章简体中文版本。

點擊這裡查看本文章正體中文版本。

This post was translated with AI assistance — let me know if anything sounds off!

---

Practical Application Records of Design Patterns

Design Patterns Applied to Issues and Solutions Encountered When Encapsulating the Socket.IO Client Library Requirements

Photo by Daniel McCullough

Introduction

This article documents a real development need, using Design Patterns to solve problems; it covers the background, the actual problem scenario (What?), the reason for applying the Pattern (Why?), and how it is implemented (How?). It is recommended to read from the beginning for better coherence.

This article introduces four scenarios encountered during the development of this requirement and seven design patterns used to address these scenarios.

Background

Organizational Structure

Our company split into multiple Feature Teams and a Platform Team this year. The former mainly handles user-side requirements, while the Platform Team serves internal members. One of their tasks is to introduce technology, manage infrastructure, and ensure systematic integration, paving the way for Feature Teams when developing requirements.

Current Requirements

The Feature Teams need to change the original messaging function (fetching message data via API on page load, requiring refresh to get the latest messages) to real-time communication (able to receive the latest messages instantly and send messages in real time).

Platform Team Work

The Platform Team focuses not only on immediate messaging needs but also on long-term development and reusability. After evaluation, the webSocket bidirectional communication mechanism is essential in modern apps. Beyond the current requirement, there will be many future opportunities to use it. With available resources, the team is committed to assisting in designing and developing the interface.

Goal:

• Encapsulating Pinkoi Server-Side and Socket.IO Communication, Authentication Logic

• Encapsulate the tedious operations of Socket.IO, providing an extensible and user-friendly interface based on Pinkoi’s business requirements

• Unified Dual-Platform Interface (Socket.IO’s Android and iOS Client Side Libraries support different features and interfaces)

• Features do not need to understand the Socket.IO mechanism

• Features do not require managing complex connection states on the client side

• In the future, if two-way webSocket communication is needed, it can be used directly.

Time and Manpower:

• One person assigned to iOS and one to Android respectively

• Development Schedule: Duration 3 weeks

Technical Details

The feature will be supported on Web, iOS, and Android platforms; it will use the webSocket bidirectional communication protocol. The backend plans to use the Socket.io service directly.

First, note that Socket != WebSocket

Regarding Socket and WebSocket, as well as technical details, you can refer to the following two articles:

• Differences between Socket, Websocket, and Socket.io

• Why not use socket directly and instead define a new websocket?

In short:

Socket is an abstract interface for the TCP/UDP transport layer, while WebSocket is a transport protocol at the application layer.
The relationship between Socket and WebSocket is like that between a dog and a hot dog—there is no relation.

Socket.IO is an abstraction layer built on top of Engine.IO, which itself is a wrapper for using WebSocket. Each layer only handles communication between the layer above and below it, and direct operations across layers are not allowed (e.g., Socket.IO cannot directly manipulate the WebSocket connection).

Socket.IO/Engine.IO implements many convenient features beyond basic WebSocket connections (e.g., offline event sending, HTTP-like request mechanism, Room/Group system, etc.).

The main responsibility of the Platform Team is to bridge the logic between Socket.IO and the Pinkoi Server Side, providing support for upper-level Feature Teams during feature development.

Socket.IO Swift Client has pitfalls

• It has not been updated for a long time (the latest version is still from 2019), so it is unclear if it is still being maintained.

• Client & Server Side Socket IO versions must match. On the server side, you can add {allowEIO3: true}, or specify the same version on the client side using .version. Otherwise, the connection will fail.

• Naming conventions, interfaces, and official website examples often do not match.

• The Socket.io official examples all use the Web for demonstration, but the Swift Client does not necessarily fully support all features described on the official site.
  In this implementation, we found that the iOS library does not support offline event sending mechanism
  (we implemented this ourselves, please continue reading).

It is recommended to test if the mechanism you want is supported before adopting Socket.IO.

Socket.IO Swift Client is a wrapper based on the Starscream WebSocket Library and can fall back to using Starscream if needed.

Background information ends here. Now, let's get to the main topic.

Design Patterns

Design patterns are essentially solutions to common problems in software design. You don’t have to use design patterns to develop software, design patterns may not fit every scenario, and no one says you can’t create new design patterns yourself.

The Catalog of Design Patterns

However, the existing design patterns (The 23 Gang of Four Design Patterns) are common knowledge in software design. When mentioning a XXX Pattern, everyone immediately has the corresponding architectural blueprint in mind, requiring no further explanation. This makes subsequent maintenance easier to understand, and since these methods are industry-validated, there is less need to spend time reviewing object dependencies. Choosing the appropriate pattern for the right scenario can reduce communication and maintenance costs and improve development efficiency.

Design patterns can be combined, but it is not recommended to drastically change existing patterns, forcefully apply them without reason, or use patterns outside their intended category (e.g., using the Chain of Responsibility pattern to create objects). Doing so defeats their purpose and may confuse future maintainers.

Design Patterns Mentioned in This Article:

• Singleton Pattern

• Flyweight Pattern

• Factory Pattern

• Command Pattern

• Finite-State Machine + State Pattern

• Chain Of Responsibility

• Builder Pattern

Each will be explained later, detailing the context used and the reason for its use.

This article focuses on the application of Design Patterns rather than the operation of Socket.IO. Some examples are simplified for clarity and cannot be used as real Socket.IO wrappers.

Due to space limitations, this article will not detail the structure of each design pattern. Please click the links for each pattern to understand their structure before continuing to read.

The demo code will be written in Swift.

Use Case 1.

What?

• Using the same Path on different pages or objects to request a Connection can reuse and obtain the same object.

• Connection should be an abstract interface and not directly depend on the Socket.IO object.

Why?

• Reduce memory usage and the time and data costs of repeated connections.

• Reserve space for future replacement with other frameworks

How?

• Singleton Pattern: A creational pattern that ensures a class has only one instance.

• Flyweight Pattern: A structural pattern that shares common state among multiple objects for reuse.

• Factory Pattern: A creational pattern that abstracts object creation methods, allowing external substitution.

Real Case Usage:

• Singleton Pattern: The ConnectionManager is a single instance throughout the app lifecycle, used to manage Connection access operations.

• Flyweight Pattern: ConnectionPool is, as the name suggests, a shared pool of Connections. Connections are retrieved from this pool, and the logic includes returning an existing Connection from the pool when the URL path is the same.
  ConnectionHandler serves as the external operator and state manager for Connection.

• Factory Pattern: ConnectionFactory works with the Flyweight Pattern above. When the pool has no reusable Connection, this factory interface is used to create one.

import Combine
import Foundation

protocol Connection {
    var url: URL {get}
    var id: UUID {get}
    
    init(url: URL)
    
    func connect()
    func disconnect()
    
    func sendEvent(_ event: String)
    func onEvent(_ event: String) -> AnyPublisher<Data?, Never>
}

protocol ConnectionFactory {
    func create(url: URL) -> Connection
}

class ConnectionPool {
    
    private let connectionFactory: ConnectionFactory
    private var connections: [Connection] = []
    
    init(connectionFactory: ConnectionFactory) {
        self.connectionFactory = connectionFactory
    }
    
    func getOrCreateConnection(url: URL) -> Connection {
        if let connection = connections.first(where: { $0.url == url }) {
            return connection
        } else {
            let connection = connectionFactory.create(url: url)
            connections.append(connection)
            return connection
        }
    }
    
}

class ConnectionHandler {
    private let connection: Connection
    init(connection: Connection) {
        self.connection = connection
    }
    
    func getConnectionUUID() -> UUID {
        return connection.id
    }
}

class ConnectionManager {
    static let shared = ConnectionManager(connectionPool: ConnectionPool(connectionFactory: SIOConnectionFactory()))
    private let connectionPool: ConnectionPool
    private init(connectionPool: ConnectionPool) {
        self.connectionPool = connectionPool
    }
    
    //
    func requestConnectionHandler(url: URL) -> ConnectionHandler {
        let connection = connectionPool.getOrCreateConnection(url: url)
        return ConnectionHandler(connection: connection)
    }
}

// Socket.IO Implementation
class SIOConnection: Connection {
    let url: URL
    let id: UUID = UUID()
    
    required init(url: URL) {
        self.url = url
        //
    }
    
    func connect() {
        //
    }
    
    func disconnect() {
        //
    }
    
    func sendEvent(_ event: String) {
        //
    }
    
    func onEvent(_ event: String) -> AnyPublisher<Data?, Never> {
        //
        return PassthroughSubject<Data?, Never>().eraseToAnyPublisher()
    }
}

class SIOConnectionFactory: ConnectionFactory {
    func create(url: URL) -> Connection {
        //
        return SIOConnection(url: url)
    }
}
//

print(ConnectionManager.shared.requestConnectionHandler(url: URL(string: "wss://pinkoi.com/1")!).getConnectionUUID().uuidString)
print(ConnectionManager.shared.requestConnectionHandler(url: URL(string: "wss://pinkoi.com/1")!).getConnectionUUID().uuidString)

print(ConnectionManager.shared.requestConnectionHandler(url: URL(string: "wss://pinkoi.com/2")!).getConnectionUUID().uuidString)

// output:
// D99F5429-1C6D-4EB5-A56E-9373D6F37307
// D99F5429-1C6D-4EB5-A56E-9373D6F37307
// 599CF16F-3D7C-49CF-817B-5A57C119FE31

Use Case 2.

What?

As described in the background technical details, the Send Event of the Socket.IO Swift Client does not support offline sending (while the Web/Android versions of the library do), so the iOS side needs to implement this feature on its own.

The amazing thing is that Socket.IO Swift Client - onEvent supports offline subscription.

Why?

• Unified Cross-Platform Functionality

• Code is easy to understand

How?

• Command Pattern: A behavioral pattern that encapsulates operations into objects, allowing queuing, delaying, canceling, and other collective actions.

• Command Pattern: SIOManager is the lowest-level wrapper for communicating with Socket.IO. Its send and request methods operate on Socket.IO Send Events. When the current Socket.IO connection is offline, the request parameters are stored in bufferedCommands. Once reconnected, these commands are processed one by one (First In First Out).

protocol BufferedCommand {
    var sioManager: SIOManagerSpec? { get set }
    var event: String { get }
    
    func execute()
}

struct SendBufferedCommand: BufferedCommand {
    let event: String
    weak var sioManager: SIOManagerSpec?
    
    func execute() {
        sioManager?.send(event)
    }
}

struct RequestBufferedCommand: BufferedCommand {
    let event: String
    let callback: (Data?) -> Void
    weak var sioManager: SIOManagerSpec?
    
    func execute() {
        sioManager?.request(event, callback: callback)
    }
}

protocol SIOManagerSpec: AnyObject {
    func connect()
    func disconnect()
    func onEvent(event: String, callback: @escaping (Data?) -> Void)
    func send(_ event: String)
    func request(_ event: String, callback: @escaping (Data?) -> Void)
}

enum ConnectionState {
    case created
    case connected
    case disconnected
    case reconnecting
    case released
}

class SIOManager: SIOManagerSpec {
        
    var state: ConnectionState = .disconnected {
        didSet {
            if state == .connected {
                executeBufferedCommands()
            }
        }
    }
    
    private var bufferedCommands: [BufferedCommand] = []
    
    func connect() {
        state = .connected
    }
    
    func disconnect() {
        state = .disconnected
    }
    
    func send(_ event: String) {
        guard state == .connected else {
            appendBufferedCommands(connectionCommand: SendBufferedCommand(event: event, sioManager: self))
            return
        }
        
        print("Send:\(event)")
    }
    
    func request(_ event: String, callback: @escaping (Data?) -> Void) {
        guard state == .connected else {
            appendBufferedCommands(connectionCommand: RequestBufferedCommand(event: event, callback: callback, sioManager: self))
            return
        }
        
        print("request:\(event)")
    }
    
    func onEvent(event: String, callback: @escaping (Data?) -> Void) {
        //
    }
    
    func appendBufferedCommands(connectionCommand: BufferedCommand) {
        bufferedCommands.append(connectionCommand)
    }
    
    func executeBufferedCommands() {
        // First in, first out
        bufferedCommands.forEach { connectionCommand in
            connectionCommand.execute()
        }
        bufferedCommands.removeAll()
    }
    
    func removeAllBufferedCommands() {
        bufferedCommands.removeAll()
    }
}

let manager = SIOManager()
manager.send("send_event_1")
manager.send("send_event_2")
manager.request("request_event_1") { _ in
    //
}
manager.state = .connected

The same can be applied to onEvent.

Extension: You can also apply the Proxy Pattern, treating the Buffer functionality as a type of Proxy.

Use Case 3.

What?

Connection has multiple states, with ordered transitions between states, and each state allows different operations.

• Created: Object is created, allowed to -> Connected or directly enter Disconnected

• Connected: Socket.IO connected, allowed -> Disconnected

• Disconnected: Disconnected from Socket.IO, allowed -> Reconnecting, Released

• Reconnection: Attempting to reconnect to Socket.IO, allowed states -> Connected, Disconnected

• Released: The object has been marked for memory reclamation and no operations or state changes are allowed.

Why?

• The logic and expression of states and state transitions are complex.

• Restricting operations based on states (e.g., when State = Released, calling Send Event is not allowed). Using simple if…else makes the code hard to maintain and read.

How?

• Finite State Machine: Manages transitions between states

• State Pattern: A behavioral pattern where an object changes its behavior based on its state.

• Finite State Machine: SIOConnectionStateMachine is the state machine implementation, currentSIOConnectionState is the current state, and created, connected, disconnected, reconnecting, released list the possible states this machine can switch to.
  enterXXXState() throws implements the allowed and disallowed (throw error) transitions when entering a certain state from the current state.

• State Pattern: SIOConnectionState is an abstract interface for operation methods used by all states.

protocol SIOManagerSpec: AnyObject {
    func connect()
    func disconnect()
    func onEvent(event: String, callback: @escaping (Data?) -> Void)
    func send(_ event: String)
    func request(_ event: String, callback: @escaping (Data?) -> Void)
}

enum ConnectionState {
    case created
    case connected
    case disconnected
    case reconnecting
    case released
}

class SIOManager: SIOManagerSpec {
        
    var state: ConnectionState = .disconnected {
        didSet {
            if state == .connected {
                executeBufferedCommands()
            }
        }
    }
    
    private var bufferedCommands: [BufferedCommand] = []
    
    func connect() {
        state = .connected
    }
    
    func disconnect() {
        state = .disconnected
    }
    
    func send(_ event: String) {
        guard state == .connected else {
            appendBufferedCommands(connectionCommand: SendBufferedCommand(event: event, sioManager: self))
            return
        }
        
        print("Send:\(event)")
    }
    
    func request(_ event: String, callback: @escaping (Data?) -> Void) {
        guard state == .connected else {
            appendBufferedCommands(connectionCommand: RequestBufferedCommand(event: event, callback: callback, sioManager: self))
            return
        }
        
        print("request:\(event)")
    }
    
    func onEvent(event: String, callback: @escaping (Data?) -> Void) {
        //
    }
    
    func appendBufferedCommands(connectionCommand: BufferedCommand) {
        bufferedCommands.append(connectionCommand)
    }
    
    func executeBufferedCommands() {
        // First in, first out
        bufferedCommands.forEach { connectionCommand in
            connectionCommand.execute()
        }
        bufferedCommands.removeAll()
    }
    
    func removeAllBufferedCommands() {
        bufferedCommands.removeAll()
    }
}

let manager = SIOManager()
manager.send("send_event_1")
manager.send("send_event_2")
manager.request("request_event_1") { _ in
    //
}
manager.state = .connected

//

class SIOConnectionStateMachine {
    
    private(set) var currentSIOConnectionState: SIOConnectionState!

    private var created: SIOConnectionState!
    private var connected: SIOConnectionState!
    private var disconnected: SIOConnectionState!
    private var reconnecting: SIOConnectionState!
    private var released: SIOConnectionState!
    
    init() {
        self.created = SIOConnectionCreatedState(stateMachine: self)
        self.connected = SIOConnectionConnectedState(stateMachine: self)
        self.disconnected = SIOConnectionDisconnectedState(stateMachine: self)
        self.reconnecting = SIOConnectionReconnectingState(stateMachine: self)
        self.released = SIOConnectionReleasedState(stateMachine: self)
        
        self.currentSIOConnectionState = created
    }
    
    func enterConnected() throws {
        if [created.connectionState, reconnecting.connectionState].contains(currentSIOConnectionState.connectionState) {
            enter(connected)
        } else {
            throw SIOConnectionStateMachineError("\(currentSIOConnectionState.connectionState) can't enter to Connected")
        }
    }
    
    func enterDisconnected() throws {
        if [created.connectionState, connected.connectionState, reconnecting.connectionState].contains(currentSIOConnectionState.connectionState) {
            enter(disconnected)
        } else {
            throw SIOConnectionStateMachineError("\(currentSIOConnectionState.connectionState) can't enter to Disconnected")
        }
    }

    func enterReconnecting() throws {
        if [disconnected.connectionState].contains(currentSIOConnectionState.connectionState) {
            enter(reconnecting)
        } else {
            throw SIOConnectionStateMachineError("\(currentSIOConnectionState.connectionState) can't enter to Reconnecting")
        }
    }

    func enterReleased() throws {
        if [disconnected.connectionState].contains(currentSIOConnectionState.connectionState) {
            enter(released)
        } else {
            throw SIOConnectionStateMachineError("\(currentSIOConnectionState.connectionState) can't enter to Released")
        }
    }
    
    private func enter(_ state: SIOConnectionState) {
        currentSIOConnectionState = state
    }
}


protocol SIOConnectionState {
    var connectionState: ConnectionState { get }
    var stateMachine: SIOConnectionStateMachine { get }
    init(stateMachine: SIOConnectionStateMachine)

    func onConnected() throws
    func onDisconnected() throws
    
    
    func connect(socketManager: SIOManagerSpec) throws
    func disconnect(socketManager: SIOManagerSpec) throws
    func release(socketManager: SIOManagerSpec) throws
    
    func request(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws
    func onEvent(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws
    func send(socketManager: SIOManagerSpec, event: String) throws
}

struct SIOConnectionStateMachineError: Error {
    let message: String

    init(_ message: String) {
        self.message = message
    }

    var localizedDescription: String {
        return message
    }
}

class SIOConnectionCreatedState: SIOConnectionState {
    
    let connectionState: ConnectionState = .created
    let stateMachine: SIOConnectionStateMachine
    
    required init(stateMachine: SIOConnectionStateMachine) {
        self.stateMachine = stateMachine
    }

    func onConnected() throws {
        try stateMachine.enterConnected()
    }
    
    func onDisconnected() throws {
        try stateMachine.enterDisconnected()
    }
    
    func release(socketManager: SIOManagerSpec) throws {
        throw SIOConnectionStateMachineError("ConnectedState can't release!")
    }
    
    func onEvent(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func request(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func send(socketManager: SIOManagerSpec, event: String) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func connect(socketManager: SIOManagerSpec) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func disconnect(socketManager: SIOManagerSpec) throws {
        throw SIOConnectionStateMachineError("CreatedState can't disconnect!")
    }
}

class SIOConnectionConnectedState: SIOConnectionState {
    
    let connectionState: ConnectionState = .connected
    let stateMachine: SIOConnectionStateMachine
    
    required init(stateMachine: SIOConnectionStateMachine) {
        self.stateMachine = stateMachine
    }
    
    func onConnected() throws {
        //
    }
    
    func onDisconnected() throws {
        try stateMachine.enterDisconnected()
    }
    
    func release(socketManager: SIOManagerSpec) throws {
        throw SIOConnectionStateMachineError("ConnectedState can't release!")
    }
    
    func onEvent(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func request(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func send(socketManager: SIOManagerSpec, event: String) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func connect(socketManager: SIOManagerSpec) throws {
        throw SIOConnectionStateMachineError("ConnectedState can't connect!")
    }
    
    func disconnect(socketManager: SIOManagerSpec) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
}

class SIOConnectionDisconnectedState: SIOConnectionState {
    
    let connectionState: ConnectionState = .disconnected
    let stateMachine: SIOConnectionStateMachine
    
    required init(stateMachine: SIOConnectionStateMachine) {
        self.stateMachine = stateMachine
    }

    func onConnected() throws {
        try stateMachine.enterConnected()
    }
    
    func onDisconnected() throws {
        //
    }
    
    func release(socketManager: SIOManagerSpec) throws {
        try stateMachine.enterReleased()
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func onEvent(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func request(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func send(socketManager: SIOManagerSpec, event: String) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func connect(socketManager: SIOManagerSpec) throws {
        try stateMachine.enterReconnecting()
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func disconnect(socketManager: SIOManagerSpec) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
}

class SIOConnectionReconnectingState: SIOConnectionState {
    
    let connectionState: ConnectionState = .reconnecting
    let stateMachine: SIOConnectionStateMachine
    
    required init(stateMachine: SIOConnectionStateMachine) {
        self.stateMachine = stateMachine
    }

    func onConnected() throws {
        try stateMachine.enterConnected()
    }
    
    func onDisconnected() throws {
        try stateMachine.enterDisconnected()
    }
    
    func release(socketManager: SIOManagerSpec) throws {
        throw SIOConnectionStateMachineError("ReconnectState can't release!")
    }
    
    func onEvent(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func request(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func send(socketManager: SIOManagerSpec, event: String) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
    
    func connect(socketManager: SIOManagerSpec) throws {
        throw SIOConnectionStateMachineError("ReconnectState can't connect!")
    }
    
    func disconnect(socketManager: SIOManagerSpec) throws {
        // allow
        // can use Helper to reduce the repeating code
        // e.g. helper.XXX(socketManager: SIOManagerSpec, ....)
    }
}

class SIOConnectionReleasedState: SIOConnectionState {
    
    let connectionState: ConnectionState = .released
    let stateMachine: SIOConnectionStateMachine
    
    required init(stateMachine: SIOConnectionStateMachine) {
        self.stateMachine = stateMachine
    }

    func onConnected() throws {
        throw SIOConnectionStateMachineError("ReleasedState can't onConnected!")
    }
    
    func onDisconnected() throws {
        throw SIOConnectionStateMachineError("ReleasedState can't onDisconnected!")
    }
    
    func release(socketManager: SIOManagerSpec) throws {
        throw SIOConnectionStateMachineError("ReleasedState can't release!")
    }
    
    func request(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws {
        throw SIOConnectionStateMachineError("ReleasedState can't request!")
    }
    
    func onEvent(socketManager: SIOManagerSpec, event: String, callback: @escaping (Data?) -> Void) throws {
        throw SIOConnectionStateMachineError("ReleasedState can't receiveOn!")
    }
    
    func send(socketManager: SIOManagerSpec, event: String) throws {
        throw SIOConnectionStateMachineError("ReleasedState can't send!")
    }
    
    func connect(socketManager: SIOManagerSpec) throws {
        throw SIOConnectionStateMachineError("ReleasedState can't connect!")
    }
    
    func disconnect(socketManager: SIOManagerSpec) throws {
        throw SIOConnectionStateMachineError("ReleasedState can't disconnect!")
    }
}

do {
    let stateMachine = SIOConnectionStateMachine()
    // mock on socket.io connect:
    // socketIO.on(connect){
    try stateMachine.currentSIOConnectionState.onConnected()
    try stateMachine.currentSIOConnectionState.send(socketManager: manager, event: "test")
    try stateMachine.currentSIOConnectionState.release(socketManager: manager)
    try stateMachine.currentSIOConnectionState.send(socketManager: manager, event: "test")
    // }
} catch {
    print("error: \(error)")
}

// output:
// error: SIOConnectionStateMachineError(message: "ConnectedState can\'t release!")

Use Case 3.

What?

Combining scenarios 1 and 2, with the ConnectionPool flyweight pool and State Pattern for state management; we continue to extend. As stated in the background goal, the Feature side does not need to handle the connection mechanism behind the Connection. Therefore, we created a poller (named ConnectionKeeper) that periodically scans the strongly held Connections in the ConnectionPool and performs actions when the following situations occur:

• Connection is in use and the status is not Connected: change the status to Reconnecting and attempt to reconnect

• Connection is no longer in use and the status is Connected: change the status to Disconnected

• Connection is no longer in use and its status is Disconnected: change status to Released and remove it from the ConnectionPool

Why?

• Three operations have a hierarchical relationship and are mutually exclusive (disconnected -> released or reconnecting)

• Flexible swapping and adding scenario operations

• If not encapsulated, the three conditions and operations can only be written directly within the method (making it difficult to test the logic).

• e.g:

if !connection.isOccupie() && connection.state == .connected then
... connection.disconnected()
else if !connection.isOccupie() && state == .released then
... connection.release()
else if connection.isOccupie() && state == .disconnected then
... connection.reconnecting()
end

How?

• Chain Of Responsibility: A behavioral pattern, as the name suggests, is a chain where each node has a corresponding operation. After receiving input, a node can decide to handle it or pass it to the next node. Another real-world example is the iOS Responder Chain.

By definition, the Chain of Responsibility Pattern does not allow a node to process data and then pass it to the next node for further processing. If you handle it, finish it; otherwise, don’t handle it at all.

If the above scenario fits better, it should be the Interceptor Pattern.

• Chain of responsibility: ConnectionKeeperHandler is the abstract node of the chain. The canExcute method is specially extracted to avoid the situation where this node processes the request but then wants to call the next node to continue execution. handle links the nodes in the chain, and excute contains the logic of how to handle the request if processing is needed.
  ConnectionKeeperHandlerContext is used to store the necessary data, where isOccupie indicates whether the connection is currently in use.

enum ConnectionState {
    case created
    case connected
    case disconnected
    case reconnecting
    case released
}

protocol Connection {
    var connectionState: ConnectionState {get}
    var url: URL {get}
    var id: UUID {get}
    
    init(url: URL)
    
    func connect()
    func reconnect()
    func disconnect()
    
    func sendEvent(_ event: String)
    func onEvent(_ event: String) -> AnyPublisher<Data?, Never>
}

// Socket.IO Implementation
class SIOConnection: Connection {
    let connectionState: ConnectionState = .created
    let url: URL
    let id: UUID = UUID()
    
    required init(url: URL) {
        self.url = url
        //
    }
    
    func connect() {
        //
    }
    
    func disconnect() {
        //
    }
    
    func reconnect() {
        //
    }
    
    func sendEvent(_ event: String) {
        //
    }
    
    func onEvent(_ event: String) -> AnyPublisher<Data?, Never> {
        //
        return PassthroughSubject<Data?, Never>().eraseToAnyPublisher()
    }
}

//

struct ConnectionKeeperHandlerContext {
    let connection: Connection
    let isOccupie: Bool
}

protocol ConnectionKeeperHandler {
    var nextHandler: ConnectionKeeperHandler? { get set }
    
    func handle(context: ConnectionKeeperHandlerContext)
    func execute(context: ConnectionKeeperHandlerContext)
    func canExcute(context: ConnectionKeeperHandlerContext) -> Bool
}

extension ConnectionKeeperHandler {
    func handle(context: ConnectionKeeperHandlerContext) {
        if canExcute(context: context) {
            execute(context: context)
        } else {
            nextHandler?.handle(context: context)
        }
    }
}

class DisconnectedConnectionKeeperHandler: ConnectionKeeperHandler {
    var nextHandler: ConnectionKeeperHandler?
    
    func execute(context: ConnectionKeeperHandlerContext) {
        context.connection.disconnect()
    }
    
    func canExcute(context: ConnectionKeeperHandlerContext) -> Bool {
        if context.connection.connectionState == .connected && !context.isOccupie {
            return true
        }
        return false
    }
}

class ReconnectConnectionKeeperHandler: ConnectionKeeperHandler {
    var nextHandler: ConnectionKeeperHandler?
    
    func execute(context: ConnectionKeeperHandlerContext) {
        context.connection.reconnect()
    }
    
    func canExcute(context: ConnectionKeeperHandlerContext) -> Bool {
        if context.connection.connectionState == .disconnected && context.isOccupie {
            return true
        }
        return false
    }
}

class ReleasedConnectionKeeperHandler: ConnectionKeeperHandler {
    var nextHandler: ConnectionKeeperHandler?
    
    func execute(context: ConnectionKeeperHandlerContext) {
        context.connection.disconnect()
    }
    
    func canExcute(context: ConnectionKeeperHandlerContext) -> Bool {
        if context.connection.connectionState == .disconnected && !context.isOccupie {
            return true
        }
        return false
    }
}
let connection = SIOConnection(url: URL(string: "wss://pinkoi.com")!)
let disconnectedHandler = DisconnectedConnectionKeeperHandler()
let reconnectHandler = ReconnectConnectionKeeperHandler()
let releasedHandler = ReleasedConnectionKeeperHandler()
disconnectedHandler.nextHandler = reconnectHandler
reconnectHandler.nextHandler = releasedHandler

disconnectedHandler.handle(context: ConnectionKeeperHandlerContext(connection: connection, isOccupie: false))

Use Case 4.

What?

The Connection we encapsulate needs to be set up before use, such as providing the URL Path, setting Config, and so on.

Why?

• Flexible adjustment of the construction opening size

• Reusable Build Logic

• If not encapsulated, external code may use the class in unintended ways.

• e.g.:

❌
let connection = Connection()
connection.send(event) // unexpected method call, should call .connect() first
✅
let connection = Connection()
connection.connect()
connection.send(event)
// but...who knows???

How?

• Builder Pattern: A creational pattern that enables step-by-step object construction and reuse of building methods.

• Builder Pattern: SIOConnectionBuilder is the builder for Connection, responsible for setting and storing data used to construct a Connection; the ConnectionConfiguration abstract interface ensures that .connect() must be called before obtaining a Connection instance.

enum ConnectionState {
    case created
    case connected
    case disconnected
    case reconnecting
    case released
}

protocol Connection {
    var connectionState: ConnectionState {get}
    var url: URL {get}
    var id: UUID {get}
    
    init(url: URL)
    
    func connect()
    func reconnect()
    func disconnect()
    
    func sendEvent(_ event: String)
    func onEvent(_ event: String) -> AnyPublisher<Data?, Never>
}

// Socket.IO Implementation
class SIOConnection: Connection {
    let connectionState: ConnectionState = .created
    let url: URL
    let id: UUID = UUID()
    
    required init(url: URL) {
        self.url = url
        //
    }
    
    func connect() {
        //
    }
    
    func disconnect() {
        //
    }
    
    func reconnect() {
        //
    }
    
    func sendEvent(_ event: String) {
        //
    }
    
    func onEvent(_ event: String) -> AnyPublisher<Data?, Never> {
        //
        return PassthroughSubject<Data?, Never>().eraseToAnyPublisher()
    }
}

//
class SIOConnectionClient: ConnectionConfiguration {
    private let url: URL
    private let config: [String: Any]
    
    init(url: URL, config: [String: Any]) {
        self.url = url
        self.config = config
    }
    
    func connect() -> Connection {
        // set config
        return SIOConnection(url: url)
    }
}

protocol ConnectionConfiguration {
    func connect() -> Connection
}

class SIOConnectionBuilder {
    private(set) var config: [String: Any] = [:]
    
    func setConfig(_ config: [String: Any]) -> SIOConnectionBuilder {
        self.config = config
        return self
    }
    
    // url is required parameter
    func build(url: URL) -> ConnectionConfiguration {
        return SIOConnectionClient(url: url, config: self.config)
    }
}

let builder = SIOConnectionBuilder().setConfig(["test":123])


let connection1 = builder.build(url: URL(string: "wss://pinkoi.com/1")!).connect()
let connection2 = builder.build(url: URL(string: "wss://pinkoi.com/1")!).connect()

Extension: You can also apply the Factory Pattern here to produce SIOConnection using a factory.

The End!

The above covers the four scenarios encountered while encapsulating Socket.IO and the seven Design Patterns used to solve the problems.

Finally, here is the complete design blueprint for packaging Socket.IO this time.

The diagram differs slightly from the naming and examples in the text but represents the actual design architecture; hopefully, the original designer will share the design concept and open source it in the future.

Who?

Who designed these and was responsible for the Socket.IO wrapper project?

Sean Zheng , Android Engineer @ Pinkoi

Main architecture designer, Design Pattern evaluation and application, implemented design using Kotlin on the Android side.

ZhgChgLi , Engineer Lead/iOS Engineer @ Pinkoi

Platform Team project lead, pair programming, implementing designs on iOS using Swift, discussing and raising questions (a.k.a. just talking), and finally writing this article to share with everyone.

Further Reading

• Practical Application Record of Design Patterns — In WKWebView with Builder, Strategy & Chain of Responsibility Pattern

• Visitor Pattern in Swift (Share Object to XXX Example)

• Visitor Pattern in TableView

If you have any questions or feedback, feel free to contact me.

---

This post was originally published on Medium (View original post), and automatically converted and synced by ZMediumToMarkdown.

Improve this page on Github.

Follow Me on Medium 1K+ Followers