Coupling (tính kết dính) trong phát triển di động — khái niệm chính, loại và cách giảm

Coupling là gì

Coupling (tính kết dính) là một chỉ số xác định mức độ liên kết chặt chẽ giữa một module hoặc lớp với module khác. Module này càng biết nhiều về cấu trúc nội bộ của module khác, coupling càng cao và hệ thống càng khó thay đổi. Trong một kiến trúc được thiết kế tốt, coupling phải ở mức tối thiểu — các module chỉ tương tác qua các giao diện được xác định chặt chẽ.

Có hai mặt của coupling: hướng vào (các phụ thuộc đến — bao nhiêu module phụ thuộc vào module này) và hướng ra (các phụ thuộc đi — module này phụ thuộc vào bao nhiêu module). Phân tích các chỉ số này giúp xác định các điểm nóng trong kiến trúc nơi việc thay đổi một module sẽ ảnh hưởng đến nhiều module khác. Các công cụ như IntelliJ Dependency Analyzer và Xcode Graph trực quan hóa các kết nối này.

Điều quan trọng là hiểu rằng zero coupling là không thể — các module phải tương tác bằng cách nào đó, nếu không thì đó không phải là hệ thống mà là tập hợp các chương trình riêng biệt. Nhiệm vụ của kiến trúc sư là làm cho coupling có thể quản lý và minh bạch. Lý tưởng: các module chỉ tương tác qua giao diện và chỉ truyền dữ liệu đơn giản, mà không biết về cấu trúc nội bộ của nhau. Điều này được gọi là kết dính lỏng (loose coupling).

Các loại kết dính từ yếu đến mạnh

Sáu loại coupling tạo thành một thang đo từ tốt nhất đến tệ nhất. Hiểu thang đo này giúp đánh giá mã hiện có và chọn hướng tái cấu trúc. Hầu hết các dự án di động có các loại coupling hỗn hợp, và nhiệm vụ của kiến trúc sư là thay thế dần các loại mạnh bằng các loại yếu.

Data coupling — loại tốt nhất

Data coupling (kết dính dữ liệu) — các module trao đổi chỉ dữ liệu đơn giản qua tham số phương thức. Module A gọi phương thức của module B, truyền các kiểu nguyên thủy hoặc cấu trúc đơn giản, và nhận kết quả. Module A không biết B được triển khai nội bộ như thế nào. Đây là loại coupling mong muốn nhất: nó giảm thiểu tác động của các thay đổi.

Ví dụ: EmailValidator.isValid(email: String): Boolean. Lớp tiêu dùng truyền một chuỗi và nhận một Boolean, mà không biết gì về biểu thức chính quy hoặc quy tắc xác thực bên trong validator. Thay đổi logic xác thực không yêu cầu thay đổi người tiêu dùng — coupling là tối thiểu. Data coupling là mục tiêu cho tất cả các giao diện công khai trong ứng dụng.

Stamp coupling — chấp nhận được nhưng không lý tưởng

Stamp coupling (kết dính tem) — các module trao đổi đối tượng phức hợp nhưng chỉ sử dụng một phần trường của chúng. Module A truyền một đối tượng User vào phương thức calculateDiscount, phương thức này chỉ sử dụng user.status. Vấn đề: nếu cấu trúc User thay đổi (một trường bắt buộc được thêm vào), module calculateDiscount không thay đổi, nhưng người tiêu dùng tạo đối tượng User thì thay đổi.

Trong thực tế, stamp coupling là không thể tránh khỏi và chấp nhận được nếu đối tượng được truyền là một mô hình dữ liệu tiêu chuẩn (Entity). Vấn đề phát sinh khi một module nhận toàn bộ đối tượng chỉ vì một trường duy nhất. Trong những trường hợp như vậy, tốt hơn là truyền giá trị cụ thể trực tiếp (data coupling). Giải pháp là phân tích việc sử dụng trường của bên nhận.

Control, External, Common và Content coupling

Control coupling — một module truyền cho module khác một cờ điều khiển hành vi của nó (calculate(useNewAlgorithm: Boolean)). Điều này tệ hơn stamp coupling vì module tiêu dùng phải biết các biến thể hoạt động nội bộ của module được gọi. Giải pháp: chia phương thức thành hai — calculateWithNewAlgorithm() và calculateWithLegacyAlgorithm().

External coupling — các module phụ thuộc vào một giao thức bên ngoài, định dạng dữ liệu hoặc API. Tất cả các module phân tích cùng một JSON hoặc làm việc với cùng một cơ sở dữ liệu đều có external coupling. Không thể tránh hoàn toàn, nhưng có thể cô lập: tạo một lớp ánh xạ giữa định dạng bên ngoài và các mô hình nội bộ. Common coupling — các module chia sẻ trạng thái toàn cục chung. Content coupling — loại tệ nhất, khi một module trực tiếp sửa đổi dữ liệu nội bộ của module khác.

Thang đo coupling từ data (lý tưởng) đến content (thảm họa) là một công cụ thực tế cho việc đánh giá mã. Nếu bạn thấy common hoặc content coupling trong một dự án — đó là các mục tiêu tái cấu trúc ưu tiên. Data và stamp coupling là chấp nhận được và có mặt trong mọi dự án, nhưng số lượng của chúng cần được kiểm soát.

Tại sao coupling quan trọng trong phát triển di động

Coupling cao biến quá trình phát triển thành một quy trình chậm chạp, nơi mọi thay đổi đều yêu cầu kiểm tra hàng chục module có khả năng bị hỏng. Điều này đặc biệt quan trọng trong phát triển di động: các nền tảng cập nhật hàng năm (Android API Level, iOS SDK), thư viện hàng quý và yêu cầu kinh doanh liên tục. Kết dính lỏng là cách duy nhất để xử lý dòng chảy thay đổi này mà không có hồi quy liên tục.

Ví dụ thực tế: một ứng dụng di động nơi tất cả màn hình đều import trực tiếp NetworkingManager và DatabaseManager. Khi thay thế HTTP client từ Retrofit sang Ktor (Android) hoặc từ URLSession sang Alamofire (iOS), nhà phát triển sẽ phải sửa đổi từng màn hình. Với coupling thấp, chỉ cần thay đổi một triển khai ẩn sau giao diện NetworkDataSource — người tiêu dùng sẽ không nhận thấy sự thay thế.

Tác động của coupling đối với kiểm thử đơn vị cũng rất lớn. Một lớp có coupling cao (tạo trực tiếp các phụ thuộc qua hàm tạo) không thể được kiểm thử riêng biệt — nó kéo theo cơ sở dữ liệu, mạng và giao diện người dùng. Để kiểm thử lớp như vậy, bạn phải khởi động trình giả lập và chờ kiểm thử tích hợp. Một lớp có coupling thấp chấp nhận các phụ thuộc qua injection hàm tạo và có thể dễ dàng bị mock.

// Coupling cao — lớp tự tạo các phụ thuộc của nó
class ProfileViewModelHigh {
    private val api = RetrofitApi()
    private val db = RoomDatabase.getInstance()
    private val cache = MemoryCache()
}

// Coupling thấp — các phụ thuộc được truyền qua hàm tạo
class ProfileViewModelLow(
    private val api: ApiService,
    private val db: DatabaseService,
    private val cache: CacheService
)

Trong trường hợp đầu tiên, ProfileViewModelHigh bị ràng buộc chặt chẽ với các triển khai cụ thể — thay thế Retrofit bằng Ktor yêu cầu thay đổi mã ViewModel. Trong trường hợp thứ hai, ProfileViewModelLow chỉ phụ thuộc vào các giao diện, mà triển khai của chúng được cung cấp từ bên ngoài. Kiểm thử lớp thứ hai rất đơn giản: truyền các triển khai mock và xác minh logic mà không cần trình giả lập.

Các mẫu giảm coupling

Nguyên tắc Đảo ngược Phụ thuộc (D trong SOLID) là nền tảng để giảm coupling. Nguyên tắc này chỉ thị phụ thuộc vào trừu tượng, không phải vào triển khai cụ thể. Thay vì một lớp trực tiếp tạo đối tượng RetrofitApi, nó nên nhận một giao diện ApiService. Điều này chuyển sự phụ thuộc từ một thư viện cụ thể lên mức trừu tượng, có thể được thay thế mà không thay đổi người tiêu dùng.

Mẫu Observer (hoặc các phiên bản phản ứng của nó — StateFlow, Combine Publishers) giảm coupling giữa nguồn dữ liệu và người đăng ký. Người đăng ký không biết dữ liệu đến từ đâu — nó chỉ phản ứng với các thay đổi. Điều này tách rời người gửi và người nhận: có thể thêm một nguồn dữ liệu mới mà không thay đổi người đăng ký hiện có. EventBus và SharedFlow hoạt động theo cùng nguyên tắc.

Mẫu Bridge tách rời trừu tượng khỏi triển khai, cho phép chúng thay đổi độc lập. Trong phát triển di động, Bridge được sử dụng, ví dụ, cho các module phụ thuộc nền tảng: một giao diện ImageLoader chung với các triển khai khác nhau cho iOS (Kingfisher, Nuke) và Android (Glide, Coil). Mã làm việc với ImageLoader không phụ thuộc vào thư viện được chọn và có thể thay thế nó bằng cách đơn giản thay đổi triển khai.

Dependency Injection như công cụ quản lý coupling

Dependency Injection (DI) là công cụ thực tế nhất để giảm coupling trong phát triển di động. Thay vì một lớp tự tạo các phụ thuộc của nó, một container DI (Hilt, Koin, Dagger cho Android; Swinject, Factory cho iOS) cung cấp chúng từ bên ngoài. Lớp nhận các phụ thuộc qua injection hàm tạo, phương thức hoặc thuộc tính, mà không biết về các triển khai cụ thể.

DI ghi lại một cách rõ ràng các phụ thuộc của lớp: chỉ cần nhìn vào hàm tạo để hiểu lớp tương tác với những module nào. Nếu hàm tạo chấp nhận 8 tham số từ các lớp khác nhau — đó là dấu hiệu của coupling quá mức cần tái cấu trúc. Thông lệ tốt là không quá 3-4 phụ thuộc cho mỗi lớp. Số lượng lớn hơn chỉ ra vi phạm Nguyên tắc Trách nhiệm Đơn lẻ và coupling quá mức.

DI cũng đơn giản hóa kiểm thử: cho mỗi bài kiểm tra bạn tạo một lớp với các phụ thuộc mock, mà không cần cơ sở dữ liệu hoặc mạng thực. Trong Flutter, DI được triển khai qua Provider, Riverpod hoặc GetIt. Bất kể framework nào, mục tiêu là một: giảm kết dính giữa các module bằng cách làm cho các phụ thuộc trở nên rõ ràng và có thể thay thế. Sử dụng DI trong dự án di động đã là tiêu chuẩn thực tế từ những năm 2020.

// Container DI xây dựng đồ thị phụ thuộc
protocol AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User
}

final class AuthService: AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User {
        // triển khai
    }
}

// ViewModel không biết về dịch vụ cụ thể — chỉ biết giao thức
final class LoginViewModel {
    private let auth: AuthServiceProtocol

    init(auth: AuthServiceProtocol) {
        self.auth = auth
    }
}

// DI Container là nơi duy nhất các kiểu cụ thể được tạo
final class DIContainer {
    lazy var authService: AuthServiceProtocol = AuthService()
    lazy var loginViewModel: LoginViewModel {
        LoginViewModel(auth: self.authService)
    }
}

Ở đây, LoginViewModel chỉ phụ thuộc vào giao thức AuthServiceProtocol, không phải AuthService cụ thể. Thay thế triển khai (ví dụ, chuyển từ Firebase Auth sang máy chủ tùy chỉnh) chỉ yêu cầu thay đổi trong DIContainer. Tất cả người tiêu dùng của AuthServiceProtocol vẫn không bị ảnh hưởng — coupling được giảm thiểu thông qua trừu tượng và DI.