মোবাইল ডেভেলপমেন্টে কাপলিং (Coupling) — মূল ধারণা, প্রকার এবং কীভাবে কমানো যায়

কাপলিং কী

কাপলিং (Coupling) একটি মেট্রিক যা নির্ধারণ করে একটি মডিউল বা ক্লাস অপরটির সাথে কতটা দৃঢ়ভাবে সংযুক্ত। একটি মডিউল অপরের অভ্যন্তরীণ কাঠামো সম্পর্কে যত বেশি জানে, কাপলিং তত বেশি এবং সিস্টেম পরিবর্তন করা তত কঠিন। একটি সু-পরিকল্পিত আর্কিটেকচারে, কাপলিং ন্যূনতম হওয়া উচিত — মডিউলগুলি শুধুমাত্র কঠোরভাবে সংজ্ঞায়িত ইন্টারফেসের মাধ্যমে যোগাযোগ করে।

কাপলিংয়ের দুটি দিক রয়েছে: অ্যাফারেন্ট (আগত নির্ভরতা — কতগুলি মডিউল এটির উপর নির্ভর করে) এবং এফারেন্ট (বহির্গামী নির্ভরতা — এটি কতগুলি মডিউলের উপর নির্ভর করে)। এই মেট্রিকগুলি বিশ্লেষণ করলে আর্কিটেকচারের হট স্পটগুলি চিহ্নিত করতে সাহায্য করে যেখানে একটি মডিউল পরিবর্তন করলে অনেকগুলি অন্যগুলি প্রভাবিত হবে। IntelliJ Dependency Analyzer এবং Xcode Graph-এর মতো টুলগুলি এই সংযোগগুলি দৃশ্যমান করে।

এটা বোঝা গুরুত্বপূর্ণ যে শূন্য কাপলিং অসম্ভব — মডিউলগুলিকে কোনো না কোনোভাবে যোগাযোগ করতে হবে, অন্যথায় এটি একটি সিস্টেম নয় বরং বিচ্ছিন্ন প্রোগ্রামের একটি সেট। আর্কিটেক্টের কাজ হল কাপলিংকে পরিচালনাযোগ্য এবং স্বচ্ছ করা। আদর্শ: মডিউলগুলি শুধুমাত্র ইন্টারফেসের মাধ্যমে যোগাযোগ করে এবং শুধুমাত্র সরল ডেটা পাস করে, একে অপরের অভ্যন্তরীণ কাঠামো সম্পর্কে না জেনে। একে লুজ কাপলিং (লুজ কাপলিং) বলা হয়।

দুর্বল থেকে শক্তিশালীতে কাপলিংয়ের প্রকার

ছয় প্রকার কাপলিং সেরা থেকে খারাপ পর্যন্ত একটি স্কেল গঠন করে। এই স্কেল বোঝা বিদ্যমান কোড মূল্যায়ন এবং রিফ্যাক্টরিংয়ের দিকনির্দেশনা নির্বাচনে সাহায্য করে। অধিকাংশ মোবাইল প্রজেক্টে মিশ্র কাপলিং প্রকার থাকে এবং আর্কিটেক্টের কাজ হল ধীরে ধীরে শক্তিশালী প্রকারগুলিকে দুর্বল প্রকার দিয়ে প্রতিস্থাপন করা।

Data coupling — সর্বোত্তম প্রকার

Data coupling (ডেটা কাপলিং) — মডিউলগুলি মেথড প্যারামিটারের মাধ্যমে শুধুমাত্র সরল ডেটা বিনিময় করে। মডিউল A, মডিউল B-এর মেথড কল করে, প্রিমিটিভ বা সরল কাঠামো পাস করে এবং ফলাফল পায়। মডিউল A জানে না B অভ্যন্তরীণভাবে কীভাবে বাস্তবায়িত। এটি কাপলিংয়ের সবচেয়ে কাঙ্ক্ষিত প্রকার: এটি পরিবর্তনের প্রভাবকে ন্যূনতম করে।

উদাহরণ: EmailValidator.isValid(email: String): Boolean। ভোক্তা ক্লাস একটি স্ট্রিং পাস করে এবং একটি বুলিয়ান পায়, ভ্যালিডেটরের ভিতরে রেগুলার এক্সপ্রেশন বা বৈধকরণ নিয়ম সম্পর্কে কোনো ধারণা না রেখে। বৈধকরণ লজিক পরিবর্তন করলে ভোক্তার পরিবর্তনের প্রয়োজন হয় না — কাপলিং ন্যূনতম। Data coupling একটি অ্যাপ্লিকেশনের সমস্ত পাবলিক ইন্টারফেসের লক্ষ্য।

Stamp coupling — গ্রহণযোগ্য কিন্তু আদর্শ নয়

Stamp coupling (স্ট্যাম্প কাপলিং) — মডিউলগুলি যৌগিক অবজেক্ট বিনিময় করে কিন্তু শুধুমাত্র তাদের কিছু ফিল্ড ব্যবহার করে। মডিউল A, calculateDiscount মেথডে একটি User অবজেক্ট পাস করে, যা শুধুমাত্র user.status ব্যবহার করে। সমস্যা: যদি User কাঠামো পরিবর্তিত হয় (একটি বাধ্যতামূলক ফিল্ড যুক্ত করা হয়), calculateDiscount মডিউল পরিবর্তন হয় না, কিন্তু User অবজেক্ট তৈরি করা ভোক্তা পরিবর্তিত হয়।

অনুশীলনে, স্ট্যাম্প কাপলিং অনিবার্য এবং গ্রহণযোগ্য যদি পাস করা অবজেক্টটি একটি স্ট্যান্ডার্ড ডেটা মডেল (এন্টিটি) হয়। সমস্যা দেখা দেয় যখন একটি মডিউল শুধুমাত্র একটি ফিল্ডের জন্য পুরো অবজেক্ট পায়। এই ধরনের ক্ষেত্রে, নির্দিষ্ট মান সরাসরি পাস করা ভাল (data coupling)। সমাধান হল প্রাপক পক্ষের ফিল্ড ব্যবহার বিশ্লেষণ করা।

Control, External, Common এবং Content coupling

Control coupling — একটি মডিউল অপরটিকে একটি ফ্ল্যাগ পাস করে যা তার আচরণ নিয়ন্ত্রণ করে (calculate(useNewAlgorithm: Boolean))। এটি স্ট্যাম্প কাপলিং থেকেও খারাপ কারণ ভোক্তা মডিউলকে কলকৃত মডিউলের অভ্যন্তরীণ অপারেটিং ভেরিয়েন্টগুলি জানতে হবে। সমাধান: মেথডটিকে দুটি ভাগে ভাগ করুন — calculateWithNewAlgorithm() এবং calculateWithLegacyAlgorithm()।

External coupling — মডিউলগুলি একটি বাহ্যিক প্রোটোকল, ডেটা ফরম্যাট বা API-এর উপর নির্ভর করে। সমস্ত মডিউল যারা একই JSON পার্স করে বা একই ডেটাবেসের সাথে কাজ করে তাদের external coupling থাকে। এটি সম্পূর্ণরূপে এড়ানো যায় না, তবে এটি বিচ্ছিন্ন করা যেতে পারে: বাহ্যিক ফরম্যাট এবং অভ্যন্তরীণ মডেলের মধ্যে একটি ম্যাপিং স্তর তৈরি করুন। Common coupling — মডিউলগুলি একটি সাধারণ বৈশ্বিক অবস্থা ভাগ করে। Content coupling — সবচেয়ে খারাপ প্রকার, যখন একটি মডিউল সরাসরি অন্য মডিউলের অভ্যন্তরীণ ডেটা পরিবর্তন করে।

data (আদর্শ) থেকে content (বিপর্যয়) পর্যন্ত কাপলিং স্কেল কোড রিভিউয়ের জন্য একটি ব্যবহারিক হাতিয়ার। যদি আপনি একটি প্রজেক্টে common বা content coupling দেখেন — এগুলি অগ্রাধিকার রিফ্যাক্টরিং লক্ষ্য। Data এবং stamp coupling গ্রহণযোগ্য এবং যেকোনো প্রজেক্টে উপস্থিত, তবে তাদের পরিমাণ নিয়ন্ত্রণ করা উচিত।

মোবাইল ডেভেলপমেন্টে কাপলিং কেন গুরুত্বপূর্ণ

উচ্চ কাপলিং ডেভেলপমেন্টকে একটি ধীর প্রক্রিয়ায় পরিণত করে যেখানে প্রতিটি পরিবর্তনের জন্য কয়েক ডজন সম্ভাব্যভাবে ভাঙা মডিউল পরীক্ষা করতে হয়। এটি মোবাইল ডেভেলপমেন্টে বিশেষভাবে গুরুত্বপূর্ণ: প্ল্যাটফর্মগুলি বার্ষিক আপডেট হয় (Android API Level, iOS SDK), লাইব্রেরি ত্রৈমাসিক এবং ব্যবসায়িক প্রয়োজনীয়তা ক্রমাগত। লুজ কাপলিং ধ্রুবক রিগ্রেশন ছাড়া পরিবর্তনের এই প্রবাহ মোকাবেলার একমাত্র উপায়।

ব্যবহারিক উদাহরণ: একটি মোবাইল অ্যাপ যেখানে সমস্ত স্ক্রিন সরাসরি NetworkingManager এবং DatabaseManager ইম্পোর্ট করে। HTTP ক্লায়েন্টকে Retrofit থেকে Ktor (Android) বা URLSession থেকে Alamofire (iOS) এ পরিবর্তন করার সময়, ডেভেলপারকে প্রতিটি স্ক্রিন পরিবর্তন করতে হবে। কম কাপলিংয়ের সাথে, NetworkDataSource ইন্টারফেসের পিছনে লুকানো একটি বাস্তবায়ন পরিবর্তন করাই যথেষ্ট — ভোক্তারা প্রতিস্থাপন লক্ষ্য করবে না।

ইউনিট টেস্টিং-এ কাপলিংয়ের প্রভাবও বিশাল। উচ্চ কাপলিংযুক্ত একটি ক্লাস (কনস্ট্রাক্টরের মাধ্যমে সরাসরি নির্ভরতা তৈরি) বিচ্ছিন্নভাবে পরীক্ষা করা যায় না — এটি ডেটাবেস, নেটওয়ার্ক এবং UI টেনে আনে। এই ধরনের ক্লাস পরীক্ষা করতে, আপনাকে একটি এমুলেটর চালু করতে হবে এবং ইন্টিগ্রেশন টেস্টের জন্য অপেক্ষা করতে হবে। কম কাপলিংযুক্ত একটি ক্লাস কনস্ট্রাক্টর ইনজেকশনের মাধ্যমে নির্ভরতা গ্রহণ করে এবং সহজেই মক করা যায়।

// উচ্চ কাপলিং — ক্লাস নিজের নির্ভরতা নিজেই তৈরি করে
class ProfileViewModelHigh {
    private val api = RetrofitApi()
    private val db = RoomDatabase.getInstance()
    private val cache = MemoryCache()
}

// নিম্ন কাপলিং — নির্ভরতা কনস্ট্রাক্টরের মাধ্যমে পাস করা হয়
class ProfileViewModelLow(
    private val api: ApiService,
    private val db: DatabaseService,
    private val cache: CacheService
)

প্রথম ক্ষেত্রে, ProfileViewModelHigh নির্দিষ্ট বাস্তবায়নের সাথে দৃঢ়ভাবে আবদ্ধ — Retrofit কে Ktor দিয়ে প্রতিস্থাপন করতে ViewModel কোড পরিবর্তন প্রয়োজন। দ্বিতীয় ক্ষেত্রে, ProfileViewModelLow শুধুমাত্র ইন্টারফেসের উপর নির্ভর করে, যার বাস্তবায়ন বাইরে থেকে প্রদান করা হয়। দ্বিতীয় ক্লাস পরীক্ষা করা তুচ্ছ: মক বাস্তবায়ন পাস করুন এবং এমুলেটর ছাড়া লজিক যাচাই করুন।

কাপলিং কমানোর প্যাটার্ন

ডিপেন্ডেন্সি ইনভার্সন প্রিন্সিপল (SOLID-এ D) কাপলিং কমানোর ভিত্তি। নীতিটি কংক্রিট বাস্তবায়নের পরিবর্তে অ্যাবস্ট্রাকশনের উপর নির্ভর করার নির্দেশ দেয়। একটি ক্লাস সরাসরি RetrofitApi অবজেক্ট তৈরি করার পরিবর্তে, তাকে একটি ApiService ইন্টারফেস গ্রহণ করা উচিত। এটি একটি নির্দিষ্ট লাইব্রেরি থেকে অ্যাবস্ট্রাকশন স্তরে নির্ভরতা স্থানান্তর করে, যা ভোক্তাকে পরিবর্তন না করেই প্রতিস্থাপন করা যেতে পারে।

Observer প্যাটার্ন (বা এর রিঅ্যাকটিভ সংস্করণ — StateFlow, Combine Publishers) ডেটা উৎস এবং সাবস্ক্রাইবারের মধ্যে কাপলিং হ্রাস করে। সাবস্ক্রাইবার জানে না ডেটা কোথা থেকে আসে — সে কেবল পরিবর্তনে প্রতিক্রিয়া জানায়। এটি প্রেরক এবং প্রাপককে আলাদা করে: বিদ্যমান সাবস্ক্রাইবার পরিবর্তন না করেই একটি নতুন ডেটা উৎস যুক্ত করা যেতে পারে। EventBus এবং SharedFlow একই নীতিতে কাজ করে।

Bridge প্যাটার্ন অ্যাবস্ট্রাকশনকে বাস্তবায়ন থেকে পৃথক করে, তাদের স্বাধীনভাবে পরিবর্তন করতে দেয়। মোবাইল ডেভেলপমেন্টে, Bridge ব্যবহার করা হয়, উদাহরণস্বরূপ, প্ল্যাটফর্ম-নির্ভর মডিউলের জন্য: iOS (Kingfisher, Nuke) এবং Android (Glide, Coil) এর জন্য বিভিন্ন বাস্তবায়নসহ একটি সাধারণ ImageLoader ইন্টারফেস। ImageLoader-এর সাথে কাজ করা কোড নির্বাচিত লাইব্রেরির উপর নির্ভর করে না এবং বাস্তবায়ন পরিবর্তন করে এটি প্রতিস্থাপন করতে পারে।

ডিপেন্ডেন্সি ইনজেকশন কাপলিং ব্যবস্থাপনার হাতিয়ার হিসেবে

ডিপেন্ডেন্সি ইনজেকশন (DI) মোবাইল ডেভেলপমেন্টে কাপলিং কমানোর সবচেয়ে ব্যবহারিক হাতিয়ার। একটি ক্লাস নিজের নির্ভরতা তৈরি করার পরিবর্তে, একটি DI কন্টেইনার (Android-এর জন্য Hilt, Koin, Dagger; iOS-এর জন্য Swinject, Factory) সেগুলি বাইরে থেকে প্রদান করে। ক্লাস কনস্ট্রাক্টর, মেথড বা প্রপার্টি ইনজেকশনের মাধ্যমে নির্ভরতা গ্রহণ করে, কংক্রিট বাস্তবায়ন সম্পর্কে অজ্ঞাত থেকে।

DI স্পষ্টভাবে নথিভুক্ত করে ক্লাসের নির্ভরতা: ক্লাস কোন মডিউলের সাথে যোগাযোগ করে তা বুঝতে শুধু কনস্ট্রাক্টর দেখুন। যদি কনস্ট্রাক্টর বিভিন্ন স্তর থেকে 8টি প্যারামিটার গ্রহণ করে — এটি অত্যধিক কাপলিংয়ের সংকেত যার রিফ্যাক্টরিং প্রয়োজন। ভালো অভ্যাস হল প্রতি ক্লাসে 3-4টির বেশি নির্ভরতা না রাখা। বেশি সংখ্যা একক দায়িত্ব লঙ্ঘন এবং অত্যধিক কাপলিং নির্দেশ করে।

DI পরীক্ষাকেও সহজ করে: প্রতিটি পরীক্ষার জন্য আপনি মক নির্ভরতাসহ একটি ক্লাস তৈরি করেন, প্রকৃত ডেটাবেস বা নেটওয়ার্কের প্রয়োজন ছাড়াই। 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-এর সমস্ত ভোক্তা অক্ষত থাকে — অ্যাবস্ট্রাকশন এবং DI-এর মাধ্যমে কাপলিং ন্যূনতম করা হয়েছে।