What Architectural Pattern Does SectionKit Use? Mediator and Protocol‑Oriented Design Explained

SectionKit employs a Mediator pattern combined with a protocol‑oriented architecture to centralize UICollectionView management and enable modular, type‑safe sections.

SectionKit is an open‑source Swift framework designed to eliminate boilerplate in complex collection view implementations. Rather than scattering delegate logic across view controllers, the library funnels all UICollectionView interactions through a single coordinator and defines strict protocol contracts for each section. This design cleanly separates Data, Logic, and View concerns while maintaining a single source of truth.

The Mediator Pattern at the Core

The architectural backbone of SectionKit is the Mediator pattern implemented via SKCManager. Located in Sources/SectionKit/CollectionBase/SKCManager.swift, this class assumes sole ownership of the UICollectionView delegate and data source responsibilities.

All delegate callbacks—such as cellForItemAt or didSelectItemAt—are routed through SKCManager, which then forwards them to the appropriate section objects. This centralization prevents view controller bloat and ensures that each section remains agnostic of the others, communicating only through the mediator.

import SectionKit
import UIKit

class DemoViewController: UIViewController {
    private lazy var collectionView = UICollectionView(
        frame: .zero,
        collectionViewLayout: SKCollectionFlowLayout()
    )
    private lazy var manager = SKCManager(sectionView: collectionView)

    override func viewDidLoad() {
        super.viewDidLoad()
        view.addSubview(collectionView)
        collectionView.frame = view.bounds
        
        // Sections are appended to the mediator
        manager.append(textSection)
    }
}

By acting as the single point of contact for the collection view, SKCManager eliminates the need for decentralized delegate implementations and manages section lifecycle events uniformly.

Protocol‑Oriented Section Architecture

Complementing the mediator is a protocol‑oriented hierarchy that defines how sections behave. The framework establishes a layered protocol stack—including SKCBaseSectionProtocol, SKCAnySectionProtocol, and SKCSectionProtocol—located under Sources/SectionKit/CollectionBaseProtocol.

These contracts enforce that every section can provide cells, handle selection events, and compute diffs without the manager needing to know concrete implementation details. This approach enables type erasure, allowing heterogeneous sections (e.g., a text section alongside an image carousel) to coexist in the same collection view while the mediator treats them uniformly.

The concrete implementation SKCSingleTypeSection<T>, found in Sources/SectionKit/CollectionSingleTypeSection/Entities/SKCSingleTypeSection.swift, demonstrates this by conforming to the protocol hierarchy and wrapping a homogeneous data array with configuration closures.

import SectionKit
import UIKit

struct Message { let title: String }

final class MessageCell: UICollectionViewCell, SKConfigurableView, SKLoadViewProtocol {
    private let label = UILabel()
    func config(_ model: Message) { label.text = model.title }
    func loadView() { contentView.addSubview(label) }
}

let textSection = SKCSingleTypeSection<MessageCell>([
    Message(title: "Hello"),
    Message(title: "World")
])
    .onCellAction(.tap) { context in
        print("Tapped row \(context.row): \(context.model.title)")
    }
    .applyStyle { style in
        style.cellStyle?.backgroundColor = .systemYellow
    }

This structure allows developers to define reusable, self‑contained sections that declare their own layout, cell type, and interaction logic through protocol conformance.

Data Flow and Update Mechanisms

SectionKit implements a publish‑subscribe data flow using Combine publishers. When a section's data mutates, it publishes a change event that SKCManager observes. The mediator then calculates the diff and invokes reloadSections or performant batch updates accordingly.

// Replace dataset; section publishes change, mediator receives update
textSection.apply([
    Message(title: "New"),
    Message(title: "Data")
])

As documented in Sources/SectionKit/AGENTS.md, this decoupled communication keeps the mediator unaware of specific section internals while ensuring the UI remains synchronized with the underlying models.

Summary

• Mediator Centralization: SKCManager in SKCManager.swift acts as the sole delegate and data source for UICollectionView, forwarding all calls to registered sections.
• Protocol Hierarchy: A layered protocol stack (SKCBaseSectionProtocol, etc.) enables type‑safe, interchangeable sections without concrete type dependencies.
• Separation of Concerns: Data models, view configuration, and business logic are encapsulated within individual sections, while the manager orchestrates the overall collection view.
• Reactive Updates: Combine publishers facilitate communication between sections and the mediator, supporting automatic diffing and reloading.

Frequently Asked Questions

How does SectionKit differ from MVVM or MVC?

SectionKit does not enforce a specific presentation pattern like MVVM or MVC; instead, it provides a structural architecture. You can embed MVVM view models inside sections (as the data source) while the framework handles the collection view plumbing through its Mediator and protocol contracts.

What is the role of SKCManager compared to UICollectionViewController?

Unlike UICollectionViewController, which typically requires subclassing and centralized delegate methods, SKCManager is a composable coordinator that owns the delegate and data source protocols. It delegates section‑specific queries to individual section objects, enabling a compositional rather than inheritance‑based architecture.

Why use protocols instead of base classes for sections?

The protocol‑oriented approach in Sources/SectionKit/CollectionBaseProtocol allows sections to retain value semantics where appropriate and avoids the fragile base class problem. Protocols enable heterogeneous collections where each section can have distinct generic constraints and cell types while presenting a uniform interface to the mediator.

Does SectionKit support mixing different cell types in one collection view?

Yes. Because all sections conform to SKCSectionProtocol (or the broader SKCAnySectionProtocol for type erasure), you can append multiple SKCSingleTypeSection instances—each with different cell types—to a single SKCManager. The mediator treats each section as a black box, rendering heterogeneous layouts within a single UICollectionView.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}