موبائل ڈویلپمنٹ میں ہم آہنگی (Cohesion): بنیادی باتیں، سطحیں اور کیسے بہتر کریں

ہم آہنگی کیا ہے

ہم آہنگی ایک میٹرک ہے جو جانچتا ہے کہ ایک کلاس یا ماڈیول کے اندر طریقے، فیلڈز اور خصوصیات منطقی طور پر کتنے جڑے ہوئے ہیں۔ اعلی ہم آہنگی والا ماڈیول ایک کام انجام دیتا ہے اور اسے مکمل کرنے کے لیے ضروری عناصر پر مشتمل ہوتا ہے۔ ادنی ہم آہنگی والا ماڈیول ایک ساتھ کئی چیزیں کرنے کی کوشش کرتا ہے — اس کے طریقے معنی میں کمزوری سے متعلق ہوتے ہیں۔

آبجیکٹ اورینٹڈ پروگرامنگ کے سیاق و سباق میں، ہم آہنگی واحد ذمہ داری کے اصول (S) سے قریبی تعلق رکھتی ہے۔ اگر ایک کلاس کی ایک واضح ذمہ داری ہے، تو اس کی ہم آہنگی عام طور پر اعلی ہوتی ہے۔ اگر ایک کلاس ایک ساتھ UI، کاروباری منطق اور نیٹ ورکنگ سنبھالتی ہے — تو ہم آہنگی ادنی ہے، اور ایسی کلاس کو تنگ ذمہ داریوں والی کئی علیحدہ کلاسوں میں تقسیم کیا جانا چاہیے۔

ہم آہنگی کو سمجھنا ڈویلپرز کو ریفیکٹرنگ کے فیصلے لینے میں مدد کرتا ہے۔ جب آپ کسی کلاس میں کوئی طریقہ دیکھتے ہیں جو کلاس کے کسی بھی فیلڈ کو استعمال نہیں کرتا، یہ ادنی ہم آہنگی کی علامت ہے۔ ایسا طریقہ یا تو کلاس میں غلط جگہ پر ہے، یا کلاس ناقص ڈیزائن کی گئی ہے۔ اعلی ہم آہنگی کے لیے کوشش کرنا کوڈ کی ہر سطح پر فن تعمیر کو بہتر بنانے کی ایک مسلسل کوشش ہے۔

ہم آہنگی کی اقسام اور سطحیں

سافٹ ویئر انجینئرنگ میں، ہم آہنگی کی سات سطحیں ممتاز کی جاتی ہیں، جو بدترین سے بہترین تک درجہ بند ہیں۔ اس پیمانے کو سمجھنا آپ کو ایک ماڈیول کے معیار کا معروضی جائزہ لینے اور ریفیکٹرنگ کی سمت متعین کرنے کی اجازت دیتا ہے۔ سطح جتنی اونچی ہوگی، کوڈ اتنا ہی زیادہ برقرار رکھنے کے قابل اور سمجھنے میں آسان ہوگا۔

ادنی ہم آہنگی: اتفاقی، منطقی اور زمانی

اتفاقی — بدترین سطح، جہاں ایک ماڈیول میں عناصر بغیر کسی منطقی تعلق کے تصادفی طور پر گروپ کیے جاتے ہیں۔ مثال: ایک Utilities کلاس جس میں تاریخ کی فارمیٹنگ، ای میل بھیجنے اور ڈسکاؤنٹ کیلکولیٹ کرنے کے طریقے ہیں۔ ایسی کلاس کو اس کے تمام طریقوں کو پڑھے بغیر نہیں سمجھا جا سکتا، اور ایک طریقہ کو تبدیل کرنا دوسروں کو توڑ سکتا ہے صرف اس لیے کہ وہ ایک ساتھ ہیں۔

منطقی — عناصر منطقی طور پر متعلقہ لیکن بنیادی طور پر مختلف کام انجام دیتے ہیں۔ parseJSON، parseXML اور parseCSV طریقوں والی ایک کلاس “تجزیہ” کے موضوع سے منطقی طور پر جڑی ہوئی ہے، لیکن ہر طریقہ بنیادی طور پر مختلف کام کرتا ہے۔ مسئلہ: جب ایک نیا فارمیٹ (YAML) شامل کیا جاتا ہے، کلاس بڑھ جاتی ہے اور اس کا انٹرفیس پھول جاتا ہے۔

زمانی — عناصر کو عملدرآمد کے وقت کے مطابق گروپ کیا جاتا ہے۔ ایک AppInitializer کلاس جو ڈیٹابیس سیٹ اپ کرتی ہے، کنفیگریشن لوڈ کرتی ہے اور اینالیٹکس شروع کرتی ہے — یہ سب ایپ اسٹارٹ اپ پر ہوتا ہے، لیکن کام خود غیر متعلق ہیں۔ بہتر ہے کہ انہیں ذمہ داری کے ہر شعبے کے لیے علیحدہ Initializers میں تقسیم کیا جائے۔

درمیانی ہم آہنگی: طریقہ کار اور مواصلاتی

طریقہ کار — اس وقت ہوتا ہے جب عناصر عملدرآمد کے ایک سلسلے سے متحد ہوتے ہیں۔ ایک “آرڈر پروسیسنگ” ماڈیول میں validateCart، processPayment اور sendConfirmation طریقے ہوتے ہیں — ہر طریقہ پچھلے کے بعد سختی سے بلایا جاتا ہے۔ یہ اتفاقی یا منطقی ہم آہنگی سے بہتر ہے، لیکن پھر بھی مثالی نہیں ہے: ہر مرحلے کو علیحدہ ماڈیول میں نکالا جا سکتا ہے۔

مواصلاتی — عناصر ایک ہی ڈیٹا کے ساتھ کام کرتے ہیں۔ getUser، updateUser اور deleteUser طریقوں والی UserService کلاس مشترکہ User ہستی سے متحد ہے۔ یہ طریقہ کار ہم آہنگی سے نمایاں طور پر بہتر ہے: کلاس کا ایک واضح ڈومین ہے۔ موبائل پروجیکٹس میں زیادہ تر Repository کلاسوں میں مواصلاتی ہم آہنگی ہوتی ہے۔

اعلی ہم آہنگی: عملیاتی

عملیاتی — اعلی ترین سطح، جہاں ماڈیول کا ہر عنصر ایک ہی کام کی انجام دہی میں حصہ لیتا ہے۔ ایک PasswordValidator کلاس جس میں ایک ہی validate طریقہ ہے جو لمبائی، حروف کی موجودگی اور پاس ورڈ کی پیچیدگی کو چیک کرتا ہے — عملیاتی ہم آہنگی کی مثال ہے۔ اگر ایسی کلاس تبدیل ہوتی ہے، تو صرف اس لیے کہ پاس ورڈ کی توثیق کے قوانین تبدیل ہو گئے ہیں۔

عملیاتی ہم آہنگی کا حصول آرکیٹیکچرل ریفیکٹرنگ کا بنیادی مقصد ہے۔ ہر کلاس میں تبدیلی کی بالکل ایک وجہ ہونی چاہیے۔ موبائل ڈویلپمنٹ میں، عملیاتی ہم آہنگی علیحدہ Use Cases، کسٹم View، فارمیٹرز اور توثیق کنندگان نکال کر حاصل کی جاتی ہے۔ ایسی ہر کلاس ذمہ داری کے واضح شعبے کے ساتھ ایک مکمل تعمیراتی بلاک ہے۔

ہم آہنگی بمقابلہ جوڑے

ہم آہنگی اور جوڑے ایک ہی معیار کے دو پہلو ہیں۔ ایک ماڈیول کے اندر ہم آہنگی جتنی زیادہ ہوگی، ماڈیولز کے درمیان جوڑے اتنا ہی کم ہوتا ہے۔ ایک اچھی طرح سے ڈیزائن کردہ نظام بیک وقت اعلی داخلی ہم آہنگی اور ڈھیلے خارجی جوڑے کے لیے کوشش کرتا ہے۔ یہ اصول 1970 کی دہائی سے سافٹ ویئر انجینئرنگ میں بنیادی تسلیم کیا جاتا ہے۔

ہم آہنگی-جوڑے کے تعلق کو ایک توازن کے طور پر سوچا جا سکتا ہے۔ اگر کوئی ڈویلپر ایک کلاس میں کئی کاموں کو ملا کر ہم آہنگی کی قربانی دیتا ہے، تو پڑوسی ماڈیولز کو زیادہ انحصار ملتا ہے — انہیں مختلف مقاصد کے لیے اس بوجھل کلاس تک رسائی حاصل کرنی پڑتی ہے، جو جوڑے کو بڑھاتا ہے۔ اس کے برعکس، چھوٹی، اعلی ہم آہنگی والی کلاسوں میں تقسیم ماڈیولز کے درمیان تعامل کے نکات کو کم کرتی ہے۔

عملی طور پر، اس کا مطلب ہے: جب آپ عملیاتی ہم آہنگی کے ساتھ ایک نئی کلاس نکالتے ہیں، تو آپ بیک وقت دوسرے ماڈیولز کو اس کے نفاذ کی تفصیلات جاننے کی ضرورت سے آزاد کرتے ہیں۔ مثال کے طور پر، EncryptionManager کو عملیاتی ہم آہنگی کے ساتھ علیحدہ کلاس میں نکالنا دوسرے ماڈیولز کو خفیہ کاری الگورتھم کی تفصیلات سمجھے بغیر ایک سادہ encrypt/decrypt انٹرفیس فراہم کرتا ہے۔

// ادنی ہم آہنگی — کلاس ایک ساتھ سب کچھ کرتی ہے
class UserManager {
    fun fetchAndSaveUser(id: String) { }
    fun parseUserJson(json: String): User { }
    fun displayUserName(user: User): String { }
    fun validateEmail(email: String): Boolean { }
}

// اعلی ہم آہنگی — ہر کلاس ایک کام حل کرتی ہے
class UserRepository {
    fun fetchUser(id: String): User { }
}

class UserJsonParser {
    fun parse(json: String): User { }
}

class UserNameFormatter {
    fun format(user: User): String { }
}

class EmailValidator {
    fun isValid(email: String): Boolean { }
}

مثال فرق ظاہر کرتی ہے: UserManager میں منطقی ہم آہنگی ہے — تمام طریقے صارفین کے بارے میں ہیں، لیکن ہر ایک بنیادی طور پر مختلف کام کرتا ہے۔ ریفیکٹرنگ کے بعد، ہر کلاس میں عملیاتی ہم آہنگی ہوتی ہے، اور جوڑے کم ہو جاتا ہے کیونکہ دوسرے ماڈیول صرف اس کلاس پر انحصار کرتے ہیں جس کی انہیں ضرورت ہے، پورے UserManager پر نہیں۔

کوڈ میں ہم آہنگی کیسے ناپیں

LCOM (طریقوں کی ہم آہنگی کی کمی) کلاس ہم آہنگی کی پیمائش کے لیے سب سے مشہور میٹرک ہے۔ LCOM شمار کرتا ہے کہ طریقوں کے کتنے جوڑے مشترکہ فیلڈز شیئر نہیں کرتے۔ قدر 0 کا مطلب مثالی ہم آہنگی ہے (تمام طریقے ایک ہی فیلڈز کے ساتھ کام کرتے ہیں)، جبکہ اعلی قدر ادنی ہم آہنگی کی نشاندہی کرتی ہے۔ LCOM4 (ایک بہتر ورژن) دوسرے طریقوں کے ذریعے عبوری روابط کو مدنظر رکھتا ہے۔

Android ڈویلپمنٹ میں، TooManyFunctions اصول کے ساتھ Detekt کے ذریعے ہم آہنگی کے میٹرکس حاصل کیے جا سکتے ہیں۔ درجنوں طریقوں والی کلاسیں جو فیلڈز کے مختلف گروپ استعمال کرتی ہیں، ممکنہ طور پر ادنی ہم آہنگی رکھتی ہیں۔ iOS میں، SwiftLint میں file_length اور function_body_length کے اصول ہیں — بالواسطہ اشارے: لمبی فائلیں اور طریقے اکثر ادنی ہم آہنگی کا اشارہ دیتے ہیں۔

ایک دستی جانچ کا طریقہ: سوال پوچھیں “کیا یہ کلاس ایک وجہ سے بدلے گی یا متعدد وجوہات سے؟” اگر آپ ایک سے زیادہ آزاد وجوہات بتا سکتے ہیں — کلاس میں ادنی ہم آہنگی ہے۔ دوسرا ٹیسٹ: “کیا اس کلاس کو دو آزاد کلاسوں میں تقسیم کیا جا سکتا ہے؟” اگر ہاں — تو کریں۔ کوڈ کے جائزوں میں باقاعدگی سے ہم آہنگی کی جانچ کرنا God کلاسوں کو روکتا ہے اور تکنیکی قرض کو کم کرتا ہے۔

موبائل پروجیکٹ میں ہم آہنگی کیسے بہتر کریں

پہلا قدم — واحد ذمہ داری کے اصول کا اطلاق کرنا۔ ہر کلاس کی ایک واضح ذمہ داری ہونی چاہیے۔ اگر کسی کلاس میں کوئی طریقہ ہے جو اس کے بنیادی کام سے متعلق نہیں ہے، تو اسے علیحدہ کلاس میں نکالیں۔ IDE میں Extract Class یا Extract Delegate تکنیک اس عمل کو خودکار کرتی ہے۔ نکالنے کے بعد، چیک کریں کہ آیا اصل کلاس زیادہ مرکوز ہو گئی ہے۔

دوسرا قدم — انٹرفیس کو آسان بنانے کے لیے Facade پیٹرن کا استعمال کرنا۔ اگر کوئی کلاس 20 طریقے فراہم کرتی ہے لیکن کلائنٹ صرف 3–4 استعمال کرتے ہیں، تو کلاس میں ادنی ہم آہنگی ہو سکتی ہے — یہ بہت زیادہ متنوع فعالیت فراہم کرتی ہے۔ طریقوں کو موضوع کے مطابق گروپ کریں، ہر گروپ کے لیے علیحدہ کلاسیں نکالیں، اور اصل کلاس کو ایک facade بنائیں یا ہٹا دیں۔

تیسرا قدم — فیلڈ گروپس پر توجہ دینا۔ اگر کسی کلاس میں ایسے فیلڈز ہیں جو صرف طریقوں کے ایک ذیلی سیٹ کے ذریعہ استعمال ہوتے ہیں — یہ ادنی ہم آہنگی کا اشارہ ہے۔ کلاس کو فیلڈ گروپس کے مطابق تقسیم کریں۔ مثال کے طور پر، اگر کسی کلاس میں userRepository، networkClient اور analyticsTracker فیلڈز ہیں، لیکن طریقوں کا پہلا گروپ صرف userRepository استعمال کرتا ہے جبکہ دوسرا networkClient استعمال کرتا ہے — یہ دو مختلف کلاسیں ہیں۔

چوتھا قدم — صوابدیدی static طریقوں والی “utility” کلاسیں بنانے سے بچنا۔ Utils یا Helpers کلاس میں موجود ہر static طریقہ ایک ماہر کلاس میں نکالنے کا امیدوار ہے۔ FormatUtils.dateToString کو DateFormatter میں لے جانا بہتر ہے، اور ValidationUtils.isValidEmail کو EmailValidator میں۔ یہ ہر کلاس کی ہم آہنگی بڑھاتا ہے اور کوڈ کو خود دستاویزی بناتا ہے۔