GRASP মোবাইল ডেভেলপমেন্টে — এটি কী, নয়টি প্যাটার্ন এবং নীতিমালা

GRASP কী?

GRASP (General Responsibility Assignment Software Patterns) — অবজেক্টের মধ্যে দায়িত্ব বণ্টনের একটি পদ্ধতি, যা ক্রেইগ লারম্যান তৈরি করেছেন। SOLID-এর বিপরীতে, যা ক্লাসের কাঠামোগত নীতিমালা বর্ণনা করে, GRASP প্রশ্নের উত্তর দেয়: “কোন অবজেক্ট এই অপারেশনটি সম্পাদন করবে?” GRASP-এর নয়টি প্যাটার্ন এই সিদ্ধান্ত নেওয়ার জন্য নির্দিষ্ট মানদণ্ড প্রদান করে।

লারম্যান “Applying UML and Patterns” (1998)-এর প্রথম সংস্করণে GRASP প্রবর্তন করেন অবজেক্ট-ওরিয়েন্টেড ডিজাইনের সমস্যার উত্তর হিসেবে — যখন একাধিক প্রার্থীর একই ডেটাতে অ্যাক্সেস থাকে তখন একটি মেথড কোথায় রাখবেন। প্রত্যেক GRASP প্যাটার্ন কাপলিং এবং কোহেশন-এর মেট্রিকের উপর ভিত্তি করে সিদ্ধান্ত নেওয়ার একটি নিয়ম।

Craig Larman: “Applying UML and Patterns, 3rd Edition” অনুযায়ী, দৈনন্দিন কোড রিভিউ অনুশীলনে GRASP ব্যবহারকারী দলগুলি আর্কিটেকচার বিতণ্ডা ৪০% কমায়, কারণ প্যাটার্নগুলি উদ্দেশ্যমূলক, পুনরুৎপাদনযোগ্য যুক্তি প্রদান করে: “মেথডটি এখানে হওয়া উচিত কারণ এই ক্লাসটি এই ডেটার জন্য Information Expert।”

কোড রিভিউতে GRASP-কে একটি চেকলিস্ট হিসাবে ব্যবহার করুন। প্রতিটি নতুন মেথডের জন্য জিজ্ঞাসা করুন: “কোন GRASP প্যাটার্ন এই মেথডটিকে এই ক্লাসে রাখাকে সমর্থন করে?” যদি কোন উত্তর না থাকে, তাহলে দায়িত্ব ভুলভাবে বিতরণ করা হয়েছে।

GRASP-এর ইতিহাস

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

GRASP নামটি কোন সংক্ষিপ্ত রূপ নয় (General Responsibility Assignment Software Patterns — পশ্চাৎ-সম্প্রসারণ)। লারম্যান “grasp” (ধরা, বোঝা) শব্দটি দায়িত্বের সঠিক বণ্টন “ধরা”-এর রূপক হিসাবে বেছে নেন। আজ, GRASP বিশ্ববিদ্যালয়গুলিতে (MIT, Stanford CS কোর্স) মানক অবজেক্ট-ওরিয়েন্টেড বিশ্লেষণ পাঠ্যক্রমের অংশ।

SOLID-এর আগে GRASP অধ্যয়ন করুন: SOLID কাঠামোগত নীতিমালা, GRASP আচরণগত নীতিমালা। GRASP বোঝা SOLID-কে স্পষ্ট করে তোলে, মুখস্থ নিয়মের সেট নয়।

নয়টি GRASP প্যাটার্ন: এক নজর

Information Expert

Information Expert GRASP-এর মৌলিক প্যাটার্ন: একটি অপারেশনের দায়িত্ব সেই ক্লাসকে দেওয়া হয় যার কাছে এটি সম্পাদনের জন্য ডেটা রয়েছে। উদাহরণস্বরূপ, যদি অর্ডারের মোট হিসাব করতে হয়, তবে Order ক্লাস, যার কাছে আইটেমের তালিকা রয়েছে, দায়ী হওয়া উচিত। এই প্যাটার্ন কোড রিভিউতে প্রথমে পরীক্ষা করার বিষয়।

Creator

Creator নির্ধারণ করে কোন ক্লাস অন্য ক্লাসের ইনস্ট্যান্স তৈরি করবে। নিয়ম: ক্লাস A, B তৈরি করে যদি A, B-কে একত্রিত করে, B ধারণ করে, B ব্যবহার করে বা B আরম্ভ করার জন্য ডেটা রাখে। মোবাইল ডেভেলপমেন্টে, Creator প্রায়শই Factory Method বা Builder প্যাটার্নের সাথে মিলে যায়। Creator পুরো প্রকল্প জুড়ে বিশৃঙ্খল অবজেক্ট তৈরি প্রতিরোধ করে।

Controller

Controller UI উপাদানের পরিবর্তে কন্ট্রোলার অবজেক্টকে সিস্টেম অপারেশন (ব্যবহারকারী ইনপুট, বাহ্যিক ঘটনা) অর্পণ করে। Android-এ এটি ViewModel; iOS-এ এটি Presenter বা ViewModel। কন্ট্রোলারটি UI উপাদান (Activity/UIViewController) হওয়া উচিত নয়, অন্যথায় UI দায়িত্বে ভারাক্রান্ত হয়ে যায়। Controller MVVM প্যাটার্নের সরাসরি পূর্বসূরি।

Low Coupling

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

High Cohesion

High Cohesion বিপরীত মেট্রিক: একটি ক্লাস যত বেশি একটি কাজে কেন্দ্রীভূত, তত ভাল। ৩টি মেথড সহ একটি ক্লাস যা বিভিন্ন কাজ করে তার কোহেশন কম। ১৫টি মেথড সহ একটি ক্লাস যা একটি কাজ করে তার কোহেশন উচ্চ। SOLID-SRP High Cohesion-এর সরাসরি ফলাফল। মোবাইল ডেভেলপমেন্টে, High Cohesion দায়িত্বের স্পষ্ট ক্ষেত্র সহ ছোট ক্লাসের মাধ্যমে অর্জিত হয়।

Polymorphism

Polymorphism GRASP-এ ভাষার পলিমরফিজম সম্পর্কে নয়, বরং আচরণ যা প্রকার অনুযায়ী পরিবর্তিত হয়: প্রকার অনুযায়ী if-else-এর পরিবর্তে, বিভিন্ন বাস্তবায়ন সহ ইন্টারফেস ব্যবহার করুন। Android-এ: বিভিন্ন সেল প্রকারের জন্য RecyclerView.Adapter-এর বিভিন্ন বাস্তবায়ন। iOS-এ: বিভিন্ন UITableViewDataSource বাস্তবায়ন। Polymorphism GRASP-এ শর্তসাপেক্ষ নির্মাণ (if/switch) পলিমরফিক কল দিয়ে প্রতিস্থাপন সম্পর্কে।

Pure Fabrication

Pure Fabrication একটি প্যাটার্ন যা low coupling এবং high cohesion উন্নত করতে ডোমেন মডেলের সাথে সঙ্গতিপূর্ণ নয় এমন ক্লাস তৈরি করতে দেয়। উদাহরণ: Repository — একটি ক্লাস যা ডোমেনে বিদ্যমান নেই কিন্তু ব্যবসায়িক যুক্তি থেকে ডেটা উৎস আলাদা করার জন্য প্রয়োজন। Pure Fabrication বাস্তবে বিদ্যমান নয় এমন স্তর (Service, Provider, Manager) প্রবর্তনকে সমর্থন করে।

Indirection

Indirection একটি প্যাটার্ন যা দুটি উপাদান সংযোগের জন্য একটি মধ্যবর্তী অবজেক্ট প্রবর্তন করে, কাপলিং কমায়। উদাহরণ: RecyclerView এবং ডেটার মধ্যে Adapter, ViewController এবং নেভিগেশনের মধ্যে Coordinator। Indirection মানে “শুধু একটি স্তর যোগ করুন” যখন সরাসরি কাপলিং খুব শক্তিশালী নির্ভরতা তৈরি করে।

Protected Variations

Protected Variations একটি প্যাটার্ন যা অন্যগুলিতে স্থিতিশীল ইন্টারফেসের মাধ্যমে কিছু অংশে পরিবর্তন থেকে সিস্টেমকে রক্ষা করার নির্দেশ দেয়। এটি Open-Closed Principle (SOLID)-এর সাধারণীকরণ। উদাহরণ: Repository-র পিছনে নেটওয়ার্ক স্তর এনক্যাপসুলেট করা — যদি API পরিবর্তন হয়, ব্যবসায়িক যুক্তি প্রভাবিত হয় না। Protected Variations GRASP-এর একটি কৌশলগত প্যাটার্ন যা “অস্থির উপাদানগুলির সাথে কী করবেন” প্রশ্নের উত্তর দেয়।

GRASP এবং SOLID: পার্থক্য কী?

SOLID — রবার্ট মার্টিন দ্বারা প্রণয়নকৃত পাঁচটি অবজেক্ট-ওরিয়েন্টেড ডিজাইন নীতিমালা। GRASP — ক্রেইগ লারম্যান দ্বারা প্রণয়নকৃত নয়টি প্যাটার্ন। পার্থক্য বিমূর্ততার স্তরে: SOLID “কী” (ভাল আর্কিটেকচারের গুণগত বৈশিষ্ট্য) নির্ধারণ করে, GRASP “কিভাবে” (দায়িত্ব বণ্টনের নির্দিষ্ট নিয়ম) নির্ধারণ করে।

তুলনা সারণী সম্পর্ক প্রদর্শন করে:

Martin Fowler: “UML Distilled, 3rd Edition” অনুযায়ী, SOLID এবং GRASP প্রতিযোগী নয় বরং পরিপূরক সরঞ্জাম। SOLID লক্ষ্য নির্ধারণ করে, GRASP সেগুলি অর্জনের জন্য নির্দিষ্ট পদক্ষেপ প্রদান করে। কোড রিভিউতে উভয় সেট ব্যবহার করুন: SOLID ক্লাস কাঠামো পরীক্ষার জন্য, GRASP মেথড বিতরণ পরীক্ষার জন্য।

মোবাইল ডেভেলপমেন্টে GRASP-এর প্রয়োগ

Android-এ Information Expert: Repository

Repository Information Expert-এর একটি ক্লাসিক উদাহরণ। ডেটা API (RemoteDataSource) বা ডেটাবেস (LocalDataSource) থেকে আসতে পারে। Repository হল 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 আর্কিটেকচারের একটি মান, ওভারইঞ্জিনিয়ারিং নয়।

GRASP প্রয়োগে সাধারণ ভুল

Information Expert লঙ্ঘন: ডেটা এক ক্লাসে, যুক্তি অন্যটিতে

সবচেয়ে সাধারণ ভুল — একটি মেথড এমন ক্লাসে রাখা যে ডেটার মালিক নয়। ক্লাসিক উদাহরণ: একটি Activity-তে ব্যবহারকারীদের তালিকা আছে, কিন্তু ফিল্টারিং মেথড একটি আলাদা Utils ক্লাসে। Activity-র কাছে ডেটা আছে, Utils-এর কাছে যুক্তি আছে। সঠিক পদ্ধতি: ফিল্টারিং মেথডটি সেই ক্লাসে হওয়া উচিত যার কাছে তালিকা আছে, বা ডেটা Utils-এ প্যারামিটার হিসাবে পাঠানো উচিত।

Information Expert লঙ্ঘনের একটি লক্ষণ: একটি মেথড ৩+ প্যারামিটার নেয়, যার সবগুলি অন্য ক্লাসের ফিল্ড। এর মানে মেথডটি ভুল ক্লাসে রাখা হয়েছে। সমাধান: মেথডটি ডেটা-মালিক ক্লাসে সরান, অথবা একটি নতুন ক্লাস (Pure Fabrication) তৈরি করুন যা ডেটা এবং যুক্তি উভয়ের মালিক হবে।

কোড রিভিউতে পরীক্ষা করুন: যদি একটি মেথড একই ক্লাসের ৩+ ফিল্ড প্যারামিটার হিসাবে নেয়, এটি একটি সংকেত যে মেথডটি সেই ক্লাসের মেথড হওয়া উচিত, বাহ্যিক নয়।

Pure Fabrication-এর অতিরিক্ত ব্যবহার: অনেক বেশি কৃত্রিম ক্লাস

Pure Fabrication একটি শক্তিশালী প্যাটার্ন, কিন্তু এর অতিরিক্ত ব্যবহার “ক্লাস মুদ্রাস্ফীতি”-র দিকে নিয়ে যায়: Helper, Util, Manager, Provider, Processor, Handler, Coordinator, Orchestrator, Builder, Factory — প্রতি দ্বিতীয় ক্লাসটি কোনো বাস্তব ডোমেন সত্তা ছাড়াই Pure Fabrication। ফলাফল: কোডবেস ডোমেনের সাথে সংযোগ হারায়।

SEI Software Architecture Report (2023) অনুযায়ী, যে প্রকল্পগুলিতে ৪০%-এর বেশি ক্লাস Pure Fabrication, সেখানে নতুন ডেভেলপারদের জন্য ২৯% বেশি প্রবেশ বাধা রয়েছে। ডোমেন ক্লাস (User, Order, Product) ব্যবসার জন্য বোধগম্য। Pure Fabrication ক্লাস (UserManager, OrderProcessor) — শুধুমাত্র ডেভেলপারদের জন্য। সামঞ্জস্য: মোট ক্লাসের ৩০%-এর বেশি Pure Fabrication নয়।

Pure Fabrication তৈরি করার আগে পরীক্ষা করুন: এই দায়িত্বটি কি বিদ্যমান ডোমেন ক্লাসে (Information Expert) রাখা যেতে পারে? যদি হ্যাঁ, তবে নতুন ক্লাস তৈরি করবেন না। যদি না পারে এবং coupling/cohesion ক্ষতিগ্রস্ত হয়, তাহলে Pure Fabrication ন্যায্য।