موبائل ڈیولپمنٹ میں آرکیٹیکچر کے اصول: یہ کیا ہیں، کتنے قسم کے ہیں اور کیسے لاگو کریں

SOLID اصول

آرکیٹیکچر کے اصول — معیاری کوڈ کی بنیاد ہیں۔ SOLID ایک مخفف ہے جو رابرٹ مارٹن («انکل باب») نے متعارف کرایا، جو آبجیکٹ اورینٹڈ ڈیزائن کے پانچ اصولوں کو بیان کرتا ہے۔ SOLID پر عمل کرنا کوڈ کو زیادہ لچکدار، قابل جانچ اور تبدیلیوں کے خلاف مزاحم بناتا ہے۔ آرکیٹیکچر کے اصولوں کی خلاف ورزی تکنیکی قرض کی ایک بڑی وجہ ہے۔

آئیے ہر اصول کا جائزہ لیتے ہیں۔ Single Responsibility Principle (SRP) — ہر کلاس میں تبدیلی کی صرف ایک وجہ ہونی چاہیے۔ Open/Closed Principle (OCP) — کلاسیں توسیع کے لیے کھلی ہیں لیکن ترمیم کے لیے بند ہیں۔ Liskov Substitution Principle (LSP) — ذیلی اقسام کی اشیاء کو منطق کو توڑے بغیر بنیادی قسم کی اشیاء کی جگہ لینے کے قابل ہونا چاہیے۔ Interface Segregation Principle (ISP) — ایک عام انٹرفیس سے کئی مخصوص انٹرفیس بہتر ہیں۔ Dependency Inversion Principle (DIP) — ٹھوس نفاذات پر نہیں، بلکہ تجریدات پر انحصار کریں۔

SonarQube تجزیہ (2025) کے مطابق، SOLID اصولوں کی خلاف ورزی 68% تجارتی پروجیکٹس میں ہوتی ہے۔ سب سے عام مسائل SRP کی خلاف ورزی (35%) اور ISP کی خلاف ورزی (22%) ہیں۔ IT Sectr میں، ہم آرکیٹیکچر کے جائزے کے مرحلے پر SOLID کو نافذ کرتے ہیں — اس سے مسائل کو تکنیکی قرض میں تبدیل ہونے سے پہلے شناخت کرنے میں مدد ملتی ہے۔

Single Responsibility Principle (SRP)

SRP (واحد ذمہ داری کا اصول) — سب سے اہم اور ساتھ ہی سب سے زیادہ خلاف ورزی کردہ SOLID اصول۔ یہ کہتا ہے: ایک کلاس میں تبدیلی کی صرف ایک وجہ ہونی چاہیے۔ اگر ایک کلاس بہت زیادہ کام کرتی ہے تو اسے جانچنا، تبدیل کرنا اور سمجھنا مشکل ہے۔

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

// SRP کی خلاف ورزی — کلاس تین مختلف کام کرتی ہے
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. ڈیٹا کی تصدیق
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. ڈیٹابیس میں محفوظ کریں
        val user = User(email, name)
        database.save(user)
        
        // 3. اطلاع بھیجیں
        emailService.sendWelcomeEmail(email, name)
    }
}

// درستگی — تین کلاسوں میں تقسیم
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

درست شدہ ورژن میں، ہر کلاس اپنے کام کی ذمہ دار ہے: UserValidator — تصدیق کے لیے، UserRepository — محفوظ کرنے کے لیے، NotificationService — اطلاعات کے لیے۔ یہ کوڈ کو قابل جانچ اور دوبارہ استعمال کے قابل بناتا ہے — آپ تصدیق کی منطق کو تبدیل کیے بغیر ڈیٹابیس کے نفاذ کو تبدیل کر سکتے ہیں۔

GRASP اور Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — کریگ لارمین کے بیان کردہ، اشیاء کے درمیان ذمہ داری کی تقسیم کے نو آرکیٹیکچر اصول۔ SOLID کے برعکس، GRASP اس سوال کا جواب دیتا ہے کہ «کس کلاس میں یہ طریقہ ہونا چاہیے؟»۔ کلیدی نمونے: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations۔

Law of Demeter (LoD، کم سے کم وابستگی کا اصول) — ایک سادہ اصول: ایک شے کو صرف اپنے قریبی پڑوسیوں سے بات چیت کرنی چاہیے۔ a.getB().getC().doSomething() نہیں لکھنا چاہیے — یہ کلاسوں کے درمیان مضبوط وابستگی پیدا کرتا ہے۔ LoD دوبارہ استعمال کی اہلیت کو بہتر بناتا ہے اور جانچ کو آسان بناتا ہے۔

IT Sectr میں، ہم کوڈ کے جائزے کے دوران LoD کی تعمیل کی جانچ کرتے ہیں۔ اگر کوئی طریقہ تین یا زیادہ اشیاء سے «گزرتا» ہے، تو یہ اشارہ ہے کہ آرکیٹیکچر کو آسان بنانے کی ضرورت ہے۔ LoD کی خلاف ورزی بڑے پروجیکٹس میں سب سے عام Code Smell میں سے ایک ہے۔

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself)، KISS (Keep It Simple, Stupid) اور YAGNI (You Ain't Gonna Need It) — تین بنیادی آرکیٹیکچر اصول جو ہر ڈیولپر کو معلوم ہیں۔ سادگی کے باوجود، خلاف ورزیاں مسلسل ہوتی رہتی ہیں۔

DRY — کوڈ کو دہرائیں نہیں۔ اگر ایک ہی منطق دو جگہوں پر نظر آتی ہے تو اسے ایک عام طریقہ یا کلاس میں نکالیں۔ دہرانے کی غلطیاں بگز کا بنیادی ذریعہ ہیں: ایک جگہ کی درستگی دوسری جگہ لاگو کرنا بھول جاتے ہیں۔ DRY کا مطلب یہ نہیں کہ ایک جیسا کوڈ نہیں ہو سکتا — اہم بات یہ ہے کہ کاروباری منطق دہرائی نہ جائے۔

KISS — جتنا آسان، اتنا بہتر۔ بہت سے تجریدات اور وراثت والے پیچیدہ حل اکثر ضرورت سے زیادہ ہوتے ہیں۔ ایک سادہ حل سے شروع کریں اور صرف ضرورت پڑنے پر پیچیدہ بنائیں۔ YAGNI — ان خصوصیات کے لیے کوڈ نہ لکھیں جو «کسی دن بعد» ضرورت پڑ سکتی ہیں۔ یہ کوڈبیس کو پھیلانے اور دیکھ بھال کی پیچیدگی کو بڑھانے کا باعث بنتا ہے۔

DRY — Don't Repeat Yourself

DRY — یہ صرف کاپی پیسٹ کی عدم موجودگی نہیں ہے۔ یہ ایک اصول ہے جس کے مطابق علم یا منطق کا ہر ٹکڑا سسٹم میں ایک واحد، غیر مبہم نمائندگی رکھتا ہے۔ دہرانے کی غلطیاں واضح (کاپی شدہ کوڈ) اور پوشیدہ (مختلف پرتوں میں ایک ہی منطق) ہو سکتی ہیں۔

IT Sectr میں، ہم دہرائی کی غلطیوں کا پتہ لگانے کے لیے کوڈ تجزیہ میٹرکس استعمال کرتے ہیں۔ SonarQube اور Detekt جیسے ٹولز دہرائے گئے کوڈ کا فیصد دکھاتے ہیں۔ 5% سے زیادہ قدر ریفیکٹرنگ کی وجہ ہے۔ تاہم، یہ یاد رکھنا ضروری ہے: DRY کو غلط تجریدات کی قیمت پر حاصل نہیں کیا جانا چاہیے — بعض اوقات دو ایک جیسے کوڈ کے ٹکڑوں کو جیسے کا تیسا چھوڑ دینا بہتر ہوتا ہے اگر ان کو ملا دینے سے سمجھنا پیچیدہ ہو جائے۔

Separation of Concerns اور Modularity

Separation of Concerns (SoC) — ایک آرکیٹیکچر اصول جہاں نظام کو آزاد حصوں (concerns) میں تقسیم کیا جاتا ہے، ہر ایک اپنا کام حل کرتا ہے۔ ایک کلاسک مثال پرتوں میں تقسیم ہے: پریزنٹیشن، کاروباری منطق، ڈیٹا تک رسائی۔ ہر پرت صرف اپنے نیچے والی پرت پر انحصار کرتی ہے۔

Modularity (ماڈیولریٹی) — وہ درجہ جس تک نظام کو ماڈیولز میں تقسیم کیا جا سکتا ہے۔ ایک ماڈیول ایک اچھی طرح سے متعین انٹرفیس کے ساتھ منطقی طور پر متعلقہ کلاسوں کا ایک گروپ ہے۔ ماڈیولز ڈھیلے طور پر وابستہ (low coupling) اور مضبوطی سے ہم آہنگ (high cohesion) ہونے چاہئیں۔

ہم آہنگی بمقابلہ وابستگی

ہم آہنگی (Cohesion) — اس بات کا پیمانہ کہ ایک ہی ماڈیول کے اندر عناصر ایک دوسرے سے کتنے متعلق ہیں۔ اعلی ہم آہنگی اچھی ہے: ایک کلاس ایک کام کرتی ہے اور اسے اچھی طرح کرتی ہے۔ کم وابستگی (Low coupling) — اس بات کا پیمانہ کہ ماڈیول ایک دوسرے سے کتنے آزاد ہیں۔ کم وابستگی اچھی ہے: ایک ماڈیول میں تبدیلی دوسروں کو نہیں توڑتی۔

مثالی آرکیٹیکچر اعلی ہم آہنگی اور کم وابستگی ہے۔ عملی طور پر، اس کا مطلب ہے: ایک کلاس میں وہ طریقے ہوتے ہیں جو ایک ہی ڈیٹا پر کام کرتے ہیں (ہم آہنگی)، اور صرف تجریدات پر انحصار کرتی ہے، ٹھوس نفاذات پر نہیں (وابستگی)۔ عدم توازن «گاڈ آبجیکٹ» یا «سپگیٹی کوڈ» کا باعث بنتا ہے۔

تکنیکی قرض اور Code Smell

تکنیکی قرض (Technical Debt) — وارڈ کننگھم کے متعارف کردہ ایک استعارہ جو ان «سود» کو بیان کرتا ہے جو ایک ٹیم غیر بہترین آرکیٹیکچر فیصلوں اور آرکیٹیکچر کے اصولوں کی خلاف ورزی کے لیے ادا کرتی ہے۔ مالی قرض کی طرح، تکنیکی قرض جان بوجھ کر (ہم نے جلدی کرنے کا فیصلہ کیا، بعد میں دوبارہ کریں گے) اور غیر ارادی (تجربے کی کمی کی وجہ سے خراب آرکیٹیکچر) ہو سکتا ہے۔

Code Smell — کوڈ میں گہرے مسائل کی سطحی علامات۔ یہ اصطلاح مارٹن فاؤلر نے اپنی کتاب «Refactoring» میں مقبول بنائی۔ عام Code Smell: لمبے طریقے، بڑی کلاسیں، لمبی کال زنجیریں، کوڈ کی نقل، تبصروں کا ضرورت سے زیادہ استعمال (واضح کوڈ کے بجائے)۔

IT Sectr میں، تکنیکی قرض Jira میں علیحدہ کاموں کے طور پر ٹریک کیا جاتا ہے۔ ہر اسپرنٹ میں، ہم ریفیکٹرنگ اور قرض کی ادائیگی کے لیے 20% وقت مختص کرتے ہیں۔ تکنیکی قرض کے ساتھ منظم کام ہی اس صورت حال سے بچنے کا واحد طریقہ ہے جہاں ایک نئی خصوصیت شامل کرنے میں اسے شروع سے تیار کرنے سے زیادہ وقت لگتا ہے۔