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

> SectionKit uses the Mediator pattern and protocol-oriented design to simplify UICollectionView management. Achieve modular and type-safe sections with SectionKit.

- Repository: [神奇/sectionkit](https://github.com/linhay/sectionkit)
- Tags: architecture
- Published: 2026-03-06

---

**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`](https://github.com/linhay/sectionkit/blob/main/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.

```swift
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`](https://github.com/linhay/sectionkit/blob/main/Sources/SectionKit/CollectionSingleTypeSection/Entities/SKCSingleTypeSection.swift), demonstrates this by conforming to the protocol hierarchy and wrapping a homogeneous data array with configuration closures.

```swift
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.

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

```

As documented in [`Sources/SectionKit/AGENTS.md`](https://github.com/linhay/sectionkit/blob/main/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`](https://github.com/linhay/sectionkit/blob/main/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`.