اتصال (Coupling) در توسعه موبایل — مفاهیم کلیدی، انواع و روش‌های کاهش

Coupling چیست

Coupling (اتصال) معیاری است که تعیین می‌کند یک ماژول یا کلاس چقدر به دیگری وابسته است. هرچه یک ماژول درباره ساختار داخلی ماژول دیگر بیشتر بداند، coupling بالاتر و تغییر سیستم دشوارتر است. در معماری با طراحی خوب، coupling باید حداقل باشد — ماژول‌ها فقط از طریق رابط‌های کاملاً مشخص با هم تعامل دارند.

دو جنبه coupling متمایز می‌شود: afferent (وابستگی‌های ورودی — تعداد ماژول‌هایی که به ماژول داده شده وابسته هستند) و efferent (وابستگی‌های خروجی — ماژول داده شده به چند ماژول وابسته است). تحلیل این معیارها امکان شناسایی «نقاط داغ» در معماری را فراهم می‌کند، جایی که تغییر یک ماژول بر بسیاری دیگر تأثیر می‌گذارد. ابزارهایی مانند IntelliJ Dependency Analyzer و Xcode Graph این ارتباطات را بصری می‌کنند.

درک این نکته مهم است که coupling صفر غیرممکن است — ماژول‌ها باید به نحوی با هم تعامل داشته باشند، در غیر این صورت این یک سیستم نیست، بلکه مجموعه‌ای از برنامه‌های منزوی است. وظیفه معمار این است که coupling را قابل مدیریت و شفاف کند. ایده‌آل: ماژول‌ها فقط از طریق رابط‌ها تعامل دارند و فقط داده‌های ساده را منتقل می‌کنند، بدون آگاهی از ساختار داخلی یکدیگر. به این loose coupling (اتصال ضعیف) می‌گویند.

انواع اتصال از ضعیف به قوی

شش نوع coupling مقیاسی از بهترین تا بدترین را تشکیل می‌دهند. درک این مقیاس به ارزیابی کد موجود و انتخاب جهت بازسازی (refactoring) کمک می‌کند. بیشتر پروژه‌های موبایل انواع ترکیبی coupling دارند و وظیفه معمار این است که به تدریج انواع قوی را با انواع ضعیف جایگزین کند.

Data coupling — بهترین نوع

Data coupling (اتصال داده‌ای) — ماژول‌ها فقط داده‌های ساده را از طریق پارامترهای متد مبادله می‌کنند. ماژول A متد ماژول B را فراخوانی می‌کند، مقادیر اولیه یا ساختارهای ساده را منتقل می‌کند و نتیجه را دریافت می‌کند. ماژول A نمی‌داند B چگونه در داخل پیاده‌سازی شده است. این مطلوب‌ترین نوع coupling است: پیامدهای تغییرات را به حداقل می‌رساند.

مثال: EmailValidator.isValid(email: String): Boolean. کلاس مصرف‌کننده یک رشته ارسال می‌کند و Boolean دریافت می‌کند، بدون اطلاع از عبارات منظم یا قوانین اعتبارسنجی داخل validator. تغییر منطق اعتبارسنجی نیازی به تغییر مصرف‌کننده ندارد — coupling حداقل است. Data coupling هدف تمام رابط‌های عمومی در برنامه است.

Stamp coupling — قابل قبول اما ایده‌آل نیست

Stamp coupling (اتصال ساختاری) — ماژول‌ها اشیاء ترکیبی را مبادله می‌کنند اما فقط از بخشی از فیلدهای آنها استفاده می‌کنند. ماژول A شیء User را به متد calculateDiscount منتقل می‌کند که فقط از user.status استفاده می‌کند. مشکل: اگر ساختار User تغییر کند (فیلد اجباری اضافه شود)، ماژول calculateDiscount تغییر نمی‌کند، اما مصرف‌کننده‌ای که شیء User را ایجاد می‌کند تغییر خواهد کرد.

در عمل stamp coupling اجتناب‌ناپذیر و در صورت استاندارد بودن مدل داده (Entity) قابل قبول است. مشکل زمانی ایجاد می‌شود که ماژول یک شیء کامل را فقط برای یک فیلد دریافت می‌کند. در چنین مواردی بهتر است مقدار مشخص را مستقیماً منتقل کرد (data coupling). راه حل — تحلیل استفاده از فیلدها توسط طرف دریافت‌کننده.

Control, External, Common و Content coupling

Control coupling — یک ماژول پرچمی را به ماژول دیگر منتقل می‌کند که رفتار آن را کنترل می‌کند (calculate(useNewAlgorithm: Boolean)). این بدتر از stamp coupling است زیرا ماژول مصرف‌کننده باید گزینه‌های داخلی عملکرد ماژول فراخوانی شده را بداند. راه حل: تقسیم متد به دو متد — calculateWithNewAlgorithm() و calculateWithLegacyAlgorithm().

External coupling — ماژول‌ها به پروتکل خارجی، فرمت داده یا API وابسته هستند. تمام ماژول‌هایی که یک JSON را تجزیه می‌کنند یا با یک پایگاه داده کار می‌کنند external coupling دارند. اجتناب کامل از آن غیرممکن است، اما می‌توان آن را ایزوله کرد: ایجاد یک لایه نگاشت بین فرمت خارجی و مدل‌های داخلی. Common coupling — ماژول‌ها حالت سراسری مشترک را به اشتراک می‌گذارند. Content coupling — بدترین نوع، وقتی ماژول مستقیماً داده‌های داخلی ماژول دیگر را تغییر می‌دهد.

مقیاس coupling از data (ایده‌آل) تا content (فاجعه) — ابزاری عملی برای بازبینی کد است. اگر در پروژه common یا content coupling می‌بینید — این هدف اولویت‌دار بازسازی است. Data و stamp coupling قابل قبول هستند و در هر پروژه‌ای وجود دارند، اما تعداد آنها باید کنترل شود.

چرا coupling در توسعه موبایل حیاتی است

Coupling بالا توسعه را به فرآیندی کند تبدیل می‌کند که در آن هر تغییر نیاز به بررسی ده‌ها ماژول بالقوه شکسته دارد. در توسعه موبایل این به ویژه حیاتی است: پلتفرم‌ها سالانه به‌روز می‌شوند (Android API Level, iOS SDK)، کتابخانه‌ها — فصلی، و نیازهای کسب‌وکار — پیوسته. اتصال ضعیف تنها راه مقابله با این جریان تغییرات بدون رگرسیون‌های مداوم است.

مثال عملی: برنامه موبایلی که در آن تمام صفحه‌ها مستقیماً NetworkingManager و DatabaseManager را وارد می‌کنند. هنگام تعویض مشتری HTTP از Retrofit به Ktor (Android) یا از URLSession به Alamofire (iOS) برنامه‌نویس باید هر صفحه را اصلاح کند. با coupling پایین کافی است یک پیاده‌سازی پنهان در پشت رابط NetworkDataSource را تغییر دهید — مصرف‌کنندگان متوجه تعویض نخواهند شد.

تأثیر coupling بر تست واحد نیز بسیار زیاد است. کلاسی با coupling بالا (ایجاد مستقیم وابستگی‌ها از طریق سازنده) قابل آزمایش مجزا نیست — پایگاه داده، شبکه و UI را به همراه می‌کشد. برای آزمایش چنین کلاسی باید شبیه‌ساز را راه‌اندازی کرد و منتظر تست‌های یکپارچه‌سازی ماند. کلاسی با coupling پایین وابستگی‌ها را از طریق constructor injection دریافت می‌کند و به راحتی mock می‌شود.

// Coupling بالا — کلاس خودش وابستگی‌هایش را ایجاد می‌کند
class ProfileViewModelHigh {
    private val api = RetrofitApi()
    private val db = RoomDatabase.getInstance()
    private val cache = MemoryCache()
}

// Coupling پایین — وابستگی‌ها از طریق سازنده منتقل می‌شوند
class ProfileViewModelLow(
    private val api: ApiService,
    private val db: DatabaseService,
    private val cache: CacheService
)

در مورد اول ProfileViewModelHigh به پیاده‌سازی‌های مشخص چسبیده است — جایگزینی Retrofit با Ktor نیاز به تغییر کد ViewModel دارد. در مورد دوم ProfileViewModelLow فقط به رابط‌ها وابسته است که پیاده‌سازی‌های آنها از خارج تأمین می‌شود. آزمایش کلاس دوم ساده است: پیاده‌سازی‌های mock را منتقل می‌کنیم و منطق را بدون شبیه‌ساز بررسی می‌کنیم.

الگوهای کاهش coupling

Dependency Inversion Principle (D در SOLID) — اساس کاهش coupling است. اصل ایجاب می‌کند که به انتزاعات وابسته باشیم، نه به پیاده‌سازی‌های مشخص. به جای اینکه کلاس مستقیماً شیء RetrofitApi را ایجاد کند، باید رابط ApiService را دریافت کند. این کار وابستگی را از کتابخانه مشخص به سطح انتزاع منتقل می‌کند که بدون تغییر مصرف‌کننده قابل جایگزینی است.

Observer pattern (یا نسخه‌های واکنشی آن — StateFlow, Combine Publishers) coupling بین منبع داده و مشترکان را کاهش می‌دهد. مشترک نمی‌داند داده‌ها از کجا می‌آیند — او فقط به تغییرات واکنش نشان می‌دهد. این کار فرستنده و گیرنده را از هم جدا می‌کند: می‌توان منبع داده جدیدی اضافه کرد بدون تغییر مشترکان موجود. EventBus و SharedFlow بر اساس همین اصل کار می‌کنند.

Bridge pattern انتزاع و پیاده‌سازی را جدا می‌کند و به آنها اجازه می‌دهد مستقل از هم تغییر کنند. در توسعه موبایل Bridge برای ماژول‌های وابسته به پلتفرم استفاده می‌شود: رابط مشترک ImageLoader با پیاده‌سازی‌های مختلف برای iOS (Kingfisher, Nuke) و Android (Glide, Coil). کدی که با ImageLoader کار می‌کند به کتابخانه انتخاب شده وابسته نیست و می‌تواند آن را با تغییر ساده پیاده‌سازی جایگزین کند.

Dependency Injection به عنوان ابزار مدیریت coupling

Dependency Injection (DI) — کاربردی‌ترین ابزار کاهش coupling در توسعه موبایل است. به جای اینکه کلاس به طور مستقل وابستگی‌های خود را ایجاد کند، DI-کانتینر (Hilt, Koin, Dagger برای Android; Swinject, Factory برای iOS) آنها را از خارج تأمین می‌کند. کلاس وابستگی‌ها را از طریق constructor، method یا property injection دریافت می‌کند و از پیاده‌سازی‌های مشخص بی‌خبر می‌ماند.

DI وابستگی‌های کلاس را به طور صریح مستند می‌کند: کافی است به سازنده نگاه کنید تا بفهمید کلاس با چه ماژول‌هایی تعامل دارد. اگر سازنده 8 پارامتر از لایه‌های مختلف دریافت می‌کند — این نشانه coupling بیش از حد است که نیاز به بازسازی دارد. روش خوب — بیش از 3-4 وابستگی برای هر کلاس نباشد. تعداد بیشتر نشان‌دهنده نقض Single Responsibility و coupling بیش از حد است.

DI همچنین تست را ساده می‌کند: برای هر تست کلاسی را با وابستگی‌های mock ایجاد می‌کنید بدون نیاز به پایگاه داده یا شبکه واقعی. در Flutter DI از طریق Provider، Riverpod یا GetIt پیاده‌سازی می‌شود. صرف‌نظر از فریمورک، هدف یکسان است: تضعیف اتصال بین ماژول‌ها با شفاف و قابل جایگزینی کردن وابستگی‌ها. استفاده از DI در پروژه موبایل از دهه 2020 به بعد استاندارد واقعی است.

// DI-کانتینر گراف وابستگی را می‌سازد
protocol AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User
}

final class AuthService: AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User {
        // پیاده‌سازی
    }
}

// ViewModel از سرویس مشخص خبر ندارد — فقط پروتکل
final class LoginViewModel {
    private let auth: AuthServiceProtocol

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

// DI Container — تنها جایی که انواع مشخص ایجاد می‌شوند
final class DIContainer {
    lazy var authService: AuthServiceProtocol = AuthService()
    lazy var loginViewModel: LoginViewModel {
        LoginViewModel(auth: self.authService)
    }
}

در اینجا LoginViewModel فقط به پروتکل AuthServiceProtocol وابسته است نه AuthService مشخص. تغییر پیاده‌سازی (مثلاً انتقال از Firebase Auth به سرور خود) فقط به تغییرات در DIContainer نیاز دارد. تمام مصرف‌کنندگان AuthServiceProtocol دست نخورده باقی می‌مانند — coupling از طریق انتزاع و DI به حداقل رسیده است.