موبائل ڈیولپمنٹ میں GRASP — یہ کیا ہے، نو پیٹرنز اور اصول

GRASP کیا ہے؟

GRASP (General Responsibility Assignment Software Patterns) — اشیاء کے درمیان ذمہ داری تقسیم کرنے کا طریقہ کار جسے کریگ لارمن نے تیار کیا۔ SOLID کے برعکس، جو کلاسوں کے ساختی اصول بیان کرتا ہے، GRASP اس سوال کا جواب دیتا ہے: "یہ آپریشن کس آبجیکٹ کو انجام دینا چاہیے؟" GRASP کے نو پیٹرنز فیصلہ لینے کے لیے ٹھوس معیار فراہم کرتے ہیں۔

لارمن نے GRASP کو پہلے ایڈیشن "Applying UML and Patterns" (1998) میں آبجیکٹ اوریئنٹڈ ڈیزائن کے مسئلے کے جواب کے طور پر متعارف کرایا — طریقہ کہاں رکھا جائے جب کئی امیدوار ایک ہی ڈیٹا تک رسائی رکھتے ہوں۔ GRASP کا ہر پیٹرن فیصلہ لینے کا ایک اصول ہے جو مربوطیت (coupling) اور ہم آہنگی (cohesion) کے میٹرکس پر مبنی ہوتا ہے۔

کریگ لارمن کی کتاب "Applying UML and Patterns, 3rd Edition" کے مطابق، جو ٹیمیں روزمرہ کی کوڈ ریویو مشق میں GRASP استعمال کرتی ہیں، وہ آرکیٹیکچر کے بارے میں بحثوں میں 40% کمی لاتی ہیں، کیونکہ پیٹرنز معروضی اور دہرائی جانے والی دلیل فراہم کرتے ہیں: "یہ طریقہ یہاں ہونا چاہیے، کیونکہ یہ کلاس اس ڈیٹا کے لیے Information Expert ہے۔"

GRASP کو کوڈ ریویو کے لیے چیک لسٹ کے طور پر استعمال کریں۔ ہر نئے طریقے کے لیے سوال پوچھیں: "GRASP کا کون سا پیٹرن اس طریقہ کو بالکل اس کلاس میں رکھنے کا جواز دیتا ہے؟" اگر جواب نہ ہو — ذمہ داری غلط طریقے سے تقسیم کی گئی ہے۔

GRASP کے ظہور کی تاریخ

GRASP آبجیکٹ اوریئنٹڈ ڈیزائن کے نظریے کے عملی ضمیمے کے طور پر سامنے آیا۔ GRASP سے پہلے معمار وجدان اور تجربے پر انحصار کرتے تھے — doSomething() طریقہ کہاں رکھا جائے اس کا کوئی باقاعدہ معیار نہیں تھا۔ لارمن نے ان معیارات کو نو پیٹرنز کی شکل میں باقاعدہ بنایا، جن کے coupling اور cohesion پر قابلِ پیمائش نتائج ہیں۔

GRASP نام کوئی مخفف نہیں ہے (General Responsibility Assignment Software Patterns — پسماندہ توسیع ہے)۔ لارمن نے لفظ "grasp" (پکڑنا، سمجھنا) کو ذمہ داری کی درست تقسیم کو "پکڑنے" کے استعارے کے طور پر چنا۔ آج GRASP یونیورسٹیوں میں آبجیکٹ اوریئنٹڈ تجزیہ کے معیاری نصاب کا حصہ ہے (MIT, Stanford CS courses)۔

SOLID سے پہلے GRASP سیکھیں: SOLID ساختی اصول ہیں، GRASP رویاتی۔ GRASP کو سمجھنا SOLID کو یاد رکھے جانے والے اصولوں کا مجموعہ نہیں بلکہ واضح بنا دیتا ہے۔

GRASP کے نو پیٹرنز: جائزہ

انفارمیشن ایکسپرٹ (Information Expert)

Information Expert — GRASP کا بنیادی پیٹرن: آپریشن کی ذمہ داری اس کلاس کو دی جاتی ہے جس کے پاس اسے انجام دینے کے لیے ڈیٹا موجود ہو۔ مثال کے طور پر، اگر آرڈر کی رقم کا حساب لگانا ہو — تو ذمہ دار کلاس Order ہوگی، جس کے پاس اشیاء کی فہرست ہو۔ یہ پیٹرن وہ پہلی چیز ہے جسے کوڈ ریویو پر چیک کرنا چاہیے۔

کری ایٹر (Creator)

Creator طے کرتا ہے کہ کون سی کلاس دوسری کلاس کے انسٹینسز بنائے۔ اصول: کلاس A کلاس B بنائے اگر A میں B جمع (aggregate) ہو، B شامل ہو، B استعمال ہو یا B کو ابتدائیہ دینے کے لیے ڈیٹا ہو۔ موبائل ڈیولپمنٹ میں Creator اکثر فیکٹری میتھڈ یا Builder پیٹرن سے مطابقت رکھتا ہے۔ Creator پورے پروجیکٹ میں اشیاء کی بے ترتیب تخلیق کو روکتا ہے۔

کنٹرولر (Controller)

Controller سسٹم آپریشن (صارف کا انپٹ، بیرونی واقعہ) UI کمپوننٹ کو نہیں بلکہ کنٹرولر آبجیکٹ کو سونپتا ہے۔ Android میں یہ ViewModel ہے، iOS میں — Presenter یا ViewModel۔ کنٹرولر UI عنصر (Activity/UIViewController) نہیں ہونا چاہیے، ورنہ UI ذمہ داری سے بوجھل ہو جاتا ہے۔ Controller — MVVM پیٹرن کا براہِ راست پیشرو ہے۔

کم مربوطیت (Low Coupling)

Low Coupling — میٹرک: کلاس جتنی کم دوسری کلاسوں کے بارے میں جانتی ہے، اسے تبدیل کرنا اور جانچنا اتنا ہی آسان ہوتا ہے۔ coupling کو کم کرنا ڈیپینڈنسی انجیکشن، انٹرفیسز اور ایونٹس کے ذریعے حاصل ہوتا ہے۔ موبائل ڈیولپمنٹ میں coupling خاص طور پر اہم ہے: ماڈیولز کے درمیان سخت روابط کمپائلیشن کو سست کرتے ہیں (Gradle incremental build)۔ کم مربوطیت — ایک ہدف میٹرک ہے، کوئی مخصوص عمل نہیں۔

اعلی ہم آہنگی (High Cohesion)

High Cohesion — الٹا میٹرک: کلاس جتنی زیادہ ایک ہی کام پر مرکوز ہو، اتنی بہتر۔ 3 طریقوں والی کلاس جو مختلف کام کرتے ہیں، کم cohesion رکھتی ہے۔ 15 طریقوں والی کلاس جو ایک ہی کام کرتے ہیں — اعلی۔ SOLID-SRP — High Cohesion کا براہِ راست نتیجہ ہے۔ موبائل ڈیولپمنٹ میں High Cohesion چھوٹی کلاسوں سے حاصل ہوتی ہے جن کی ذمہ داری کا شعبہ واضح ہو۔

پولیمورفزم (Polymorphism)

Polymorphism GRASP میں — زبان کے پولیمورفزم کے بارے میں نہیں، بلکہ اس رویے کے بارے میں ہے جو ٹائپ کے مطابق تبدیل ہوتا ہے: type کے لحاظ سے if-else استعمال کرنے کی بجائے مختلف نفاذات والے انٹرفیسز استعمال کریں۔ Android میں: مختلف سیل ٹائپس کے لیے RecyclerView.Adapter کے مختلف نفاذات۔ iOS میں: UITableViewDataSource کے مختلف نفاذات۔ GRASP میں Polymorphism — مشروط ڈھانچوں (if/switch) کو پولیمورفک کالز سے تبدیل کرنے کے بارے میں ہے۔

خالص ایجاد (Pure Fabrication)

Pure Fabrication — وہ پیٹرن جو ڈومین ماڈل سے مطابقت نہ رکھنے والی کلاسوں کو بنانے کی اجازت دیتا ہے، تاکہ low coupling اور high cohesion کو بہتر بنایا جا سکے۔ مثال: Repository — ایسی کلاس جو ڈومین میں موجود نہیں، لیکن ڈیٹا سورس کو بزنس لاجک سے الگ کرنے کے لیے ضروری ہے۔ Pure Fabrication ایسی پرتیں (Service, Provider, Manager) متعارف کرانے کا جواز دیتا ہے جو حقیقت میں موجود نہیں ہیں۔

انڈائریکشن (Indirection)

Indirection — وہ پیٹرن جو دو کمپوننٹس کے درمیان رابطے کے لیے ایک بیچوان آبجیکٹ متعارف کرتا ہے، جس سے coupling کم ہوتی ہے۔ مثال: RecyclerView اور ڈیٹا کے درمیان Adapter، ViewController اور نیویگیشن کے درمیان Coordinator۔ Indirection — یعنی "بس ایک درمیانی پرت شامل کریں"، جب براہِ راست رابطہ بہت مضبوط منسلکیہ پیدا کرے۔

تغیرات کا انتظام (Protected Variations)

Protected Variations — وہ پیٹرن جو سسٹم کو ایک حصے میں ہونے والی تبدیلیوں سے دوسرے حصے میں مستحکم انٹرفیسز کے ذریعے محفوظ رکھنے کا حکم دیتا ہے۔ یہ Open-Closed Principle (SOLID) کی تعمیم ہے۔ مثال: نیٹ ورک پرت کو Repository کے پیچھے چھپانا — اگر API تبدیل ہو جائے تو بزنس لاجک متاثر نہیں ہوگی۔ Protected Variations — GRASP کا اسٹریٹجک پیٹرن ہے جو اس سوال کا جواب دیتا ہے کہ "غیر مستحکم کمپوننٹس کا کیا کیا جائے"۔

GRASP اور SOLID: فرق کیا ہے؟

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

موازنے کی جدول باہمی تعلق کو ظاہر کرتی ہے:

مارٹن فاؤلر کی کتاب "UML Distilled, 3rd Edition" کے مطابق، SOLID اور GRASP — مقابل نہیں، بلکہ باہمی تکمیلی اوزار ہیں۔ SOLID اہداف طے کرتا ہے، GRASP — ان کے حصول کے لیے ٹھوس اقدامات۔ کوڈ ریویو پر دونوں سیٹ استعمال کریں: SOLID کلاسوں کی ساخت چیک کرنے کے لیے، GRASP طریقوں کی تقسیم چیک کرنے کے لیے۔

موبائل ڈیولپمنٹ میں GRASP کا اطلاق

Android میں Information Expert: Repository

Repository — Information Expert کی کلاسک مثال ہے۔ ڈیٹا API (RemoteDataSource) یا ڈیٹابیس (LocalDataSource) سے آ سکتا ہے۔ ریپوزٹری — Information Expert ہے، کیونکہ اس کے پاس ڈیٹا کے ذرائع اور پالیسی (نیٹ ورک بمقابلہ کیش) کی معلومات ہوتی ہیں۔

// Information Expert: Repository ڈیٹا کہاں سے لینا ہے جانتا ہے
class UserRepository(
    private val api: UserApi,
    private val db: UserDao
) {
    suspend fun getUser(id: String): User {
        val cached = db.getUser(id)
        if (cached != null) return cached
        val remote = api.fetchUser(id)
        db.insert(remote)
        return remote
    }
}

UserRepository — Information Expert ہے، کیونکہ اس کے پاس ڈیٹا کے دونوں ذرائع تک رسائی ہے اور وہ کیشنگ پالیسی جانتا ہے۔ ViewModel، getUser کو کال کرتا ہے بغیر یہ جانے کہ ڈیٹا کہاں سے آیا — یہ Pure Fabrication کے ذریعے Low Coupling ہے۔

iOS میں Controller: Presenter

iOS میں Controller GRASP پیٹرن Presenter (یا ViewModel) کے ذریعے لاگو ہوتا ہے۔ UIViewController واقعہ (بٹن دبانا) حاصل کرتا ہے اور اسے Presenter کو منتقل کرتا ہے، جس میں بزنس لاجک ہوتی ہے۔ UIViewController کو یہ نہیں جاننا چاہیے کہ دبانا کیسے پروسیس ہوتا ہے۔

// Controller: Presenter بزنس لاجک پروسیس کرتا ہے
final class LoginPresenter {
    private let auth: AuthService

    func didTapLogin(email: String, pass: String) {
        guard email.contains("@") else { // توثیق
            view.showError("غلط ای میل")
            return
        }
        Task { // بزنس لاجک
            try await auth.login(email, pass)
            view.navigateToHome()
        }
    }
}

// UIViewController صرف واقعہ منتقل کرتا ہے
extension LoginViewController {
    @IBAction func loginTapped() {
        presenter.didTapLogin(email: emailField.text ?? "",
                                pass: passField.text ?? "")
    }
}

LoginPresenter — GRASP کے مطابق Controller ہے: یہ سسٹم آپریشنز (بٹن دبانا) قبول کرتا ہے اور انجام کو مربوط کرتا ہے (توثیق، AuthService کال، نیویگیشن)۔ UIViewController — صرف واقعہ منتقل کرتا ہے، Low Coupling کا خیال رکھتے ہوئے۔

Pure Fabrication: ViewModel

ViewModel — ایک کلاس جو ڈومین ماڈل سے مطابقت نہیں رکھتی (ڈومین میں "پروفائل کے لیے ViewModel" موجود نہیں)۔ Pure Fabrication اس کے وجود کا جواز دیتا ہے: یہ High Cohesion کو بہتر بناتا ہے (UI لاجک Activity/ViewController سے الگ ہوتی ہے) اور Low Coupling (Activity براہِ راست Repository پر انحصار نہیں کرتی)۔

Google: Guide to App Architecture (2024) کے مطابق، ViewModel — ڈیٹا کو دکھانے کے لیے تیار کرنے کی تجویز کردہ پرت ہے۔ Pure Fabrication کے بغیر اس لاجک کو Activity میں رکھنا پڑتا (SRP اور High Cohesion کی خلاف ورزی) یا Fragment میں (نقل)۔ Pure Fabrication — GRASP کا واحد پیٹرن ہے جو کہتا ہے "ایسی کلاس بنائیں جو حقیقت میں موجود نہیں"۔

ہر اسکرین کے لیے ViewModel بنائیں، چاہے اسکرین "بہت سادہ" لگے۔ ViewModel کے لیے Pure Fabrication — Android آرکیٹیکچر کا معیار ہے، overengineering نہیں۔

GRASP استعمال کرتے وقت عام غلطیاں

Information Expert کی خلاف ورزی: ڈیٹا ایک کلاس میں، لاجک دوسری میں

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

Information Expert کی خلاف ورزی کی علامت: طریقہ 3+ پیرامیٹرز لیتا ہے، جن میں سے سب کسی دوسری کلاس کے فیلڈز ہیں۔ اس کا مطلب ہے کہ طریقہ صحیح کلاس میں نہیں رکھا گیا۔ اصلاح: طریقے کو ڈیٹا کی مالک کلاس میں منتقل کریں یا ایک نئی کلاس بنائیں (Pure Fabrication) جو ڈیٹا اور لاجک دونوں رکھے۔

کوڈ ریویو پر چیک کریں: اگر طریقہ ایک ہی کلاس کے 3+ فیلڈز بطور پیرامیٹر لیتا ہے — یہ اس بات کی علامت ہے کہ طریقہ اس کلاس کا ہونا چاہیے، نہ کہ بیرونی۔

Pure Fabrication کا غلط استعمال: بہت زیادہ مصنوعی کلاسیں

Pure Fabrication — ایک طاقتور پیٹرن ہے، لیکن اس کا غلط استعمال "کلاس افراط" کا باعث بنتا ہے: Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — ہر دوسری کلاس بغیر حقیقی ڈومین ہستی کے Pure Fabrication ہے۔ نتیجہ: کوڈ بیس کا ڈومین سے تعلق ٹوٹ جاتا ہے۔

SEI Software Architecture Report (2023) کے مطابق، جن پروجیکٹس میں 40% سے زیادہ کلاسیں Pure Fabrication ہیں، ان میں نئے ڈیولپرز کے لیے داخلے کی حد 29% زیادہ ہوتی ہے۔ ڈومین کلاسیں (User, Order, Product) کاروبار کے لیے قابلِ فہم ہیں۔ Pure Fabrication کلاسیں (UserManager, OrderProcessor) — صرف ڈیولپرز کے لیے۔ توازن: کل کلاسوں کے 30% سے زیادہ Pure Fabrication نہیں۔

Pure Fabrication بنانے سے پہلے چیک کریں: کیا یہ ذمہ داری موجودہ ڈومین کلاس میں رکھی جا سکتی ہے (Information Expert)؟ اگر ہاں — نئی کلاس نہ بنائیں۔ اگر نہیں اور coupling/cohesion متاثر ہوتے ہیں — Pure Fabrication جائز ہے۔