Swift: A Multi-Paradigm Powerhouse—OOP, POP, and FP

Swift’s versatility truly shines when you start combining paradigms. Imagine building a networking, or web module that handles HTTP ingress and egress using the best of object-oriented programming (OOP), protocol-oriented programming (POP), and functional programming (FP). Below is a basic example that demonstrates how these paradigms come together to create a clean, maintainable, and flexible web module.

Let’s break down the implementation:

• OOP:
  We begin with a base class that represents a network request. This class encapsulates properties like the URL, HTTP method, headers, and body. By modeling a request as an object, you can later subclass it or extend it for specialized behaviors (e.g., GET vs. POST requests).

• POP:
  Instead of stuffing all behaviors into a single class hierarchy, Swift encourages you to define protocols for cross-cutting concerns—such as logging and caching. Protocols allow you to declare a contract for these behaviors, and with protocol extensions, you can supply default implementations. This approach makes it simple to mix these behaviors into any type that needs them.

• FP:
  For asynchronous networking, closures are your best friend. They let you handle responses in a functional style, mapping or filtering the resulting data before it even reaches the caller. This keeps your code both declarative and testable.

Below I’ve slung together a simple implementation that brings these concepts together:

import Foundation

// OOP: Base class for network requests
class NetworkRequest {
    let url: URL
    let httpMethod: String  // "GET", "POST", "PUT", "DELETE", etc.
    var headers: [String: String]
    var body: Data?
    
    init(url: URL, httpMethod: String = "GET", headers: [String: String] = [:], body: Data? = nil) {
        self.url = url
        self.httpMethod = httpMethod
        self.headers = headers
        self.body = body
    }
    
    func asURLRequest() -> URLRequest {
        var request = URLRequest(url: url)
        request.httpMethod = httpMethod
        request.allHTTPHeaderFields = headers
        request.httpBody = body
        return request
    }
}

// POP: Protocol for logging behavior
protocol Loggable {
    func log(_ message: String)
}
extension Loggable {
    func log(_ message: String) {
        print("LOG: \(message)")
    }
}

// POP: Protocol for caching behavior
protocol Cacheable {
    func cacheResponse(_ data: Data, for request: URLRequest)
    func cachedResponse(for request: URLRequest) -> Data?
}
extension Cacheable {
    func cacheResponse(_ data: Data, for request: URLRequest) {
        // In a real implementation, you might write to disk or memory.
        print("Caching response for \(request.url?.absoluteString ?? "unknown URL")")
    }
    
    func cachedResponse(for request: URLRequest) -> Data? {
        // For our example, we simulate a cache miss.
        return nil
    }
}

// FP & OOP: HTTP client using closures for asynchronous responses
class HTTPClient: Loggable, Cacheable {
    let session: URLSession = URLSession.shared
    
    // This method sends a network request and handles the result using a closure.
    func send(request: NetworkRequest, completion: @escaping (Result<Data, Error>) -> Void) {
        let urlRequest = request.asURLRequest()
        
        // Check if we already have a cached response.
        if let cachedData = cachedResponse(for: urlRequest) {
            log("Returning cached response for \(urlRequest.url?.absoluteString ?? "unknown URL")")
            completion(.success(cachedData))
            return
        }
        
        log("Sending \(urlRequest.httpMethod ?? "UNKNOWN") request to \(urlRequest.url?.absoluteString ?? "unknown URL")")
        
        // FP: Use a closure to handle the asynchronous response.
        session.dataTask(with: urlRequest) { data, response, error in
            if let error = error {
                self.log("Error: \(error.localizedDescription)")
                completion(.failure(error))
                return
            }
            
            guard let data = data else {
                let error = NSError(domain: "HTTPClientError", code: 0, userInfo: [NSLocalizedDescriptionKey: "No data received"])
                self.log("Error: No data received")
                completion(.failure(error))
                return
            }
            
            self.log("Received data for \(urlRequest.url?.absoluteString ?? "unknown URL")")
            self.cacheResponse(data, for: urlRequest)
            
            // FP: At this point, you could use map or filter on the data if needed.
            // For example, you might transform the JSON response:
            // let transformedData = try? JSONDecoder().decode(MyModel.self, from: data)
            completion(.success(data))
        }.resume()
    }
}

// Example usage of the networking module:

// Create a sample GET request.
guard let url = URL(string: "https://api.example.com/data") else {
    fatalError("Invalid URL")
}
let getRequest = NetworkRequest(url: url, httpMethod: "GET")

// Instantiate the HTTP client.
let client = HTTPClient()

// Send the request and handle the response using a closure (FP style).
client.send(request: getRequest) { result in
    switch result {
    case .success(let data):
        // FP: Use map/filter to transform data as needed.
        do {
            if let jsonObject = try JSONSerialization.jsonObject(with: data, options: []) as? [String: Any] {
                print("Parsed JSON: \(jsonObject)")
            } else {
                print("Unexpected data format.")
            }
        } catch {
            print("JSON parsing error: \(error)")
        }
        
    case .failure(let error):
        print("Request failed with error: \(error)")
    }
}

How It All Comes Together

• OOP:
  The NetworkRequest class encapsulates the details of an HTTP request. By centralizing properties like the URL, HTTP method, and headers, you make it easy to extend and manage your requests. If you later need specialized requests (say, a PostRequest with multipart data), you can subclass or modify this base class.

• POP:
  Instead of bloating your network client with logging and caching logic, you define the Loggable and Cacheable protocols. By providing default implementations via protocol extensions, you can mix these behaviors into any class without forcing a rigid inheritance structure. This makes your code modular and easier to maintain.

• FP:
  The HTTPClient uses closures to handle asynchronous network responses, a hallmark of functional programming. This approach makes it straightforward to chain transformations on your data. For instance, once the data is returned, you might use higher-order functions (like map or filter) to transform JSON into your app’s domain models, keeping side effects to a minimum and your code highly composable.

Final Thoughts

This example shows how Swift’s design allows you to mix paradigms to best suit your problem domain. By leveraging OOP for modeling, POP for behavior composition, and FP for handling asynchronous data flows, you create a networking module that’s both powerful and flexible. Whether you’re handling HTTP verbs for ingress (incoming data) or egress (sending data), Swift’s multi-paradigm nature gives you the tools to build robust, elegant solutions.

Happy thrashing code, keep it churning! 😜