অধ্যায় ১
The Idea of Cross-Cutting Concepts
"Once you see it, you can't unsee it."
লারাভেলের আড়ালে কাজ করা মূল প্যাটার্নগুলোর ভূমিকা। কেন এগুলো জানা জরুরি, আর কীভাবে এগুলোকে দেখতে হবে?
“এটা তো আগেও দেখেছি!”
আপনি হয়তো একটি HTTP কলে retry লজিক যোগ করছেন, অথবা ভাবছেন কীভাবে দুটি queue job একসাথে চলা বন্ধ করা যায়। হঠাৎ মনে হলো — এই সমাধানটা তো আগেও কোথাও দেখেছি! একই জায়গায় না, ফ্রেমওয়ার্কের সম্পূর্ণ অন্য কোনো অংশে। মেথডের নামগুলোও কেমন যেন চেনা।
প্রশ্ন হলো: লারাভেল কি বিভিন্ন ফিচারে একই আইডিয়া বারবার ব্যবহার করে?
উত্তর: হ্যাঁ। লারাভেল অল্প কিছু রিকারিং (বারবার ফিরে আসা) কনসেপ্টের উপর তৈরি। যে আইডিয়া একটি ফিচারকে চালায়, সেটিই চুপচাপ আরও এক ডজন ফিচারকে চালায়। এটা কাকতালীয় নয় — এটা একটি সচেতন ডিজাইন সিদ্ধান্ত, যার কারণে ফ্রেমওয়ার্ক বড় হলেও গোছানো মনে হয়।
এই বইটি কোনো সোর্স-কোড ডিপ ডাইভ নয়, আবার সব ফিচারের তালিকাও নয়। এটা অনেকটা বছরের পর বছর লারাভেল নিয়ে কাজ করা একজন সিনিয়র টিমমেটকে জিজ্ঞেস করার মতো — “আচ্ছা ভাই, লারাভেল এটা এভাবে কেন করে?” — আর সোজাসাপ্টা উত্তর পাওয়া।
Cross-Cutting Concept কী?
সংজ্ঞা
Cross-Cutting Concept হলো এমন একটি পুনঃব্যবহারযোগ্য আইডিয়া, যা কোনো একটি মডিউলে সীমাবদ্ধ নয় — বরং ডাটাবেস, কিউ, মেইল, ক্যাশ, HTTP-সহ পুরো ফ্রেমওয়ার্ক জুড়ে একইভাবে ছড়িয়ে থাকে।
আমরা সাধারণত কীভাবে শিখি?
বেশিরভাগ ডেভেলপার লারাভেল শেখেন ফিচার বাই ফিচার:
- কীভাবে request পাঠাবো
- কীভাবে job dispatch করবো
- কীভাবে কিছু cache করবো
- কীভাবে notification পাঠাবো
এটা স্বাভাবিক — টিউটোরিয়াল আর ডকুমেন্টেশন এভাবেই সাজানো। কিন্তু প্রতিটি ফিচারের নিচে একই আইডিয়া বারবার ফিরে আসে:
কেন জানা জরুরি?
নতুন ফিচার দ্রুত শেখা
Job middleware, HTTP client middleware বা bus batches — নতুন ফিচার এলে যদি চেনা প্যাটার্ন ব্যবহার করে, সাথে সাথেই বুঝে যাবেন। যত বেশি প্যাটার্ন চিনবেন, তত দ্রুত নতুন জিনিস “ক্লিক” করবে।
কোড হবে “Laravel-like”
নিজের pipeline লেখা, event দিয়ে সিস্টেম আলাদা করা, প্যাকেজে driver-based আর্কিটেকচার যোগ করা — অন্য লারাভেল ডেভেলপাররা আপনার কোড সহজেই বুঝবে, কারণ আপনারা একই ভাষায় কথা বলছেন।
ভালো ডিবাগার হওয়া
কিছু ভাঙলে আন্দাজে খোঁজার বদলে আগে থেকেই বুঝতে পারবেন সমস্যাটা কোথায় থাকতে পারে। ডিবাগিং হয়ে যায় প্যাটার্ন রিকগনিশন।
না জানলে কী হয়?
- একই কাজের জন্য বারবার নতুন কোড লেখা (Code Duplication)।
- ফ্রেমওয়ার্কের “ম্যাজিক” না বোঝায় ডিবাগিং কঠিন।
- স্কেল করার সময় অপ্রত্যাশিত বাধা।
জানলে কী লাভ?
- লারাভেলের সোর্স কোড সহজে বোঝা যায়।
- নতুন ফিচার কীভাবে কাজ করে তা আগেই আন্দাজ করা যায়।
- কোড আরও রিডেবল ও মেইনটেইনেবল হয়।
Pattern বনাম Classical Design Pattern
এই বই Gang of Four টেক্সটবুকের Strategy, Observer বা Factory-র মতো ফর্মাল “Design Pattern” নিয়ে নয়। লারাভেল সেগুলোর কিছু ব্যবহার করে, কিন্তু কঠোরভাবে মেনে চলে না — আধুনিক PHP অ্যাপের জন্য ব্যবহারিক রূপে মানিয়ে নেয়।
| লারাভেলের প্যাটার্ন | অনুপ্রেরণা | পার্থক্য |
|---|---|---|
| Pipeline | Chain of Responsibility | টেক্সটবুক ইমপ্লিমেন্টেশন নয় |
| Retry | ডিস্ট্রিবিউটেড সিস্টেমের Retry Pattern | আরও সহজ ও প্র্যাগম্যাটিক |
| Driver | Adapter Pattern | একই সমস্যা সমাধান করে, কিন্তু দেখতে একদম আলাদা |
এই বইয়ে “Pattern” মানে
একটি পুনঃব্যবহারযোগ্য কনসেপ্ট, যা লারাভেল বিভিন্ন ফিচারে একই ধরনের সমস্যা সমাধানে প্রয়োগ করে।
Classical design pattern জানা থাকলে মিল খুঁজে পাবেন; না জানলেও সমস্যা নেই — এই বই বুঝতে সেই ব্যাকগ্রাউন্ড লাগবে না।
লারাভেলের ডিজাইন দর্শন
এই প্যাটার্নগুলো হঠাৎ আসেনি — এগুলো একটি ধারাবাহিক ডিজাইন দর্শন থেকে এসেছে।
কোড পড়তে স্বাভাবিক
$response->retry(3) বা Cache::lock('key')->get() দেখলেই ডক না পড়ে বোঝা যায় কী হচ্ছে।
জ্ঞান এক জায়গা থেকে আরেক জায়গায়
HTTP client, queue job আর DB transaction-এ retry একইভাবে কাজ করে — কনসেপ্টটা একবার শিখলেই হয়। মেন্টাল মডেল সহজ থাকে।
প্র্যাগম্যাটিক
প্যাটার্নের খাতিরে প্যাটার্ন নয়। টেক্সটবুক প্যাটার্ন বদলাতে হলে বদলায়; সহজ সমাধান কাজ করলে সেটাই নেয়।
এক্সটেন্ড করার জন্য তৈরি
Drivers, middleware, macros — ফ্রেমওয়ার্ক এগুলো খুলে রেখেছে যাতে আপনি নিজের ইমপ্লিমেন্টেশন প্লাগ-ইন করতে পারেন।
একটি বাস্তব উদাহরণ
ধরুন আপনি একটি ই-কমার্স সাইট বানাচ্ছেন। অর্ডার প্লেস হওয়ার পর ৩টি কাজ হওয়া দরকার:
১. মেইল পাঠানো
ইউজারকে ইনভয়েস পাঠানো।
২. স্টক কমানো
ইনভেন্টরি আপডেট করা।
৩. SMS পাঠানো
শিপিং আপডেট দেওয়া।
প্যাটার্ন ছাড়া কোড (Bad Practice)
public function store(Request $request)
{
$order = Order::create($request->all());
// সব লজিক কন্ট্রোলারের ভেতরেই
Mail::to($request->user())->send(new OrderPlaced($order));
Inventory::decrement($order->product_id);
Sms::send('Your order is placed.');
return response()->json('Order placed');
}সমস্যা কোথায়, আর কোন অধ্যায়ে সমাধান?
| সমস্যা | সমাধান |
|---|---|
| মেইল সার্ভার এক মুহূর্তের জন্য টাইমআউট দিলে পুরো রিকোয়েস্ট ফেইল | অধ্যায় ২: Retry |
| মেইল প্রোভাইডার পুরো ডাউন | অধ্যায় ৩: Failover |
| একই ইউজার দুবার ক্লিক করলে স্টক দুবার কমে | অধ্যায় ৪: Atomic Locks |
| নতুন কাজ যোগ করতে প্রতিবার কন্ট্রোলার বদলাতে হয় | অধ্যায় ৭: Events |
| SMS প্রোভাইডার বদলাতে কোড রিরাইট | অধ্যায় ৮: Driver |
| ইউজারকে সব কাজ শেষ হওয়া পর্যন্ত অপেক্ষা করতে হয় | অধ্যায় ৯: Deferring Work |
লারাভেলকে নতুন চোখে দেখা
এই কনসেপ্টগুলো আত্মস্থ করলে আলাদা মনে হওয়া ফিচারগুলো সম্পর্কিত মনে হতে শুরু করবে। Changelog-এ নতুন কিছু পড়লেই ভাববেন — “ও, এটা তো আবার সেই pipeline প্যাটার্ন!” কোনো বাগ দেখলেই বুঝবেন কোন কনসেপ্ট জড়িত।
ফ্রেমওয়ার্কের ইন্টারনাল মুখস্থ করার দরকার নেই। শুধু সেই হাতেগোনা কয়েকটি আইডিয়া চিনতে হবে, যেগুলোতে লারাভেল বারবার ফিরে যায়।
সামনে যা আসছে
সারসংক্ষেপ ও যাচাই
মনে রাখুন
- লারাভেল অল্প কিছু আইডিয়া বিভিন্ন সাবসিস্টেমে বারবার ব্যবহার করে — এটা সচেতন ডিজাইন।
- এখানে “pattern” মানে টেক্সটবুক GoF প্যাটার্ন নয়, বরং বারবার প্রয়োগ হওয়া ব্যবহারিক কনসেপ্ট।
- প্যাটার্ন চিনলে নতুন ফিচার দ্রুত শেখা যায়, কোড Laravel-like হয়, ডিবাগিং সহজ হয়।
- Drivers, middleware, macros এক্সটেন্ড করার জন্যই তৈরি।
নিজেকে যাচাই করুন
Laravel-এর Pipeline কোন classical pattern থেকে অনুপ্রাণিত?
Chain of Responsibility — তবে লারাভেল এটা টেক্সটবুক উপায়ে ইমপ্লিমেন্ট করেনি।
একই কনসেপ্ট বিভিন্ন জায়গায় ব্যবহার করার সবচেয়ে বড় সুবিধা কী?
জ্ঞান স্থানান্তরযোগ্য হয় — একবার শিখলে সব জায়গায় চেনা যায়, ফলে মেন্টাল মডেল সহজ থাকে।
এই বই কি লারাভেলের সোর্স কোড ডিপ ডাইভ?
না। এটা বারবার ফিরে আসা আইডিয়াগুলোর মধ্যে সংযোগ দেখানোর উপর ফোকাস করে।