واقعات اور listeners کیسے کام کرتے ہیں؟

Question

Accepted Answer

Laravel کا **events اور listeners** observer pattern کو نافذ کرتا ہے — جب کچھ قابلِ غور ہوتا ہے تو آپ **event dispatch** کرتے ہیں، اور ایک یا زیادہ **listeners** اس پر ردِ عمل ظاہر کرتے ہیں۔ یہ کوڈ کو الگ کرتا ہے: event کا ذریعہ یہ نہیں جاننے کی ضرورت ہے کہ کون جواب دیتا ہے، جو concerns کی صاف الگ تھلگ کاری کو ممکن بناتا ہے۔

## Event اور listener کی تعریف

```php
// the event — a simple data carrier for "something happened"
class OrderShipped {
    public function __construct(public Order $order) {}
}

// a listener — reacts to the event
class SendShipmentNotification {
    public function handle(OrderShipped $event): void {
        Mail::to($event->order->customer)->send(new ShipmentMail($event->order));
    }
}
// generate with: php artisan make:event / make:listener
```

## Event کو dispatch کرنا

```php
// when the order ships, DISPATCH the event — all listeners run
OrderShipped::dispatch($order);
// or: event(new OrderShipped($order));
```

Event کو dispatch کرنا تمام اس کے رجسٹرڈ listeners کو متحرک کرتا ہے۔ آرڈر شپنگ کوڈ صرف یہ اعلان کرتا ہے کہ کیا ہوا — یہ نہیں جانتا (یا پرواہ نہیں کرتا) کہ ای میلز، analytics، یا دوسری ردِ عمل واقع ہو رہی ہے۔

## ایک event کے لیے متعدد listeners (decoupling)

```php
// one event can have MANY listeners — each a separate concern
OrderShipped → SendShipmentNotification    // email
            → UpdateInventory               // adjust stock
            → RecordAnalytics               // log the event
// add reactions without modifying the order-shipping code
```

یہ اہم فائدہ ہے: آپ event کو نیا ردِ عمل (ایک listener) شامل کر سکتے ہیں بغیر اس کوڈ کو چھوئے جو اسے dispatch کرتا ہے — صاف، توسیع پذیر decoupling۔

## Queued listeners (async)

```php
class SendShipmentNotification implements ShouldQueue {   // run the listener in the BACKGROUND
    public function handle(OrderShipped $event): void { ... }
}
```

`ShouldQueue` کو نافذ کرنا ایک listener کو queue کے ذریعے **غیر مطابقت کے ساتھ** چلاتا ہے — تو سست ردِ عمل (ای میل بھیجنا) جواب میں تاخیر نہیں کرتا۔

## یہ کیوں اہم ہے

Events اور listeners کوڈ کو **decoupling** کے لیے ایک مفید Laravel feature ہیں — آپ کی ایپلیکیشن کے مختلف حصوں کو سخت coupling کے بغیر واقعات پر ردِ عمل دینے دیتے ہیں، جو cross-cutting ردِ عمل اور کوڈ کو قابلِ دیکھ بھال رکھنے کے لیے قیمتی ہے۔

ji کو سمجھنا ان کو استعمال کرنے اور codebases میں ان کو پہچاننے دونوں کے لیے مفید ہے: یہ pattern آپ کو event dispatch کرنے دیتا ہے جب کچھ اہم ہوتا ہے (آرڈر شپ ہو، user رجسٹر ہو) اور متعدد آزاد listeners ردِ عمل کریں (ای میل بھیجیں، inventory اپڈیٹ کریں، analytics ریکارڈ کریں)، ہر ایک الگ concern سنبھالتے ہوئے۔

اہم فائدہ **decoupling کے ذریعے extensibility** ہے — آپ نیا ردِ عمل listener رجسٹر کر کے شامل کر سکتے ہیں بغیر اس کوڈ کو تبدیل کیے جو event dispatch کرتا ہے، concerns الگ رکھتے ہوئے اور dispatch کرنے والے کوڈ کو مرکوز رکھتے ہوئے۔

listeners کو **queued** (`ShouldQueue`) بنانے کی صلاحیت تاکہ وہ غیر مطابقت سے چلیں بھی اہم ہے، سست ردِ عمل (ای میلز، بیرونی API کالز) کو پس منظر میں ہونے دیتے ہوئے بغیر صارف کے جواب میں تاخیر کے۔

یہ جاننا کہ events/listeners کیسے کام کرتے ہیں، ان کا decoupling فائدہ، اور غیر مطابقت پروسیسنگ کے لیے queued listeners اچھی ساخت والی، توسیع پذیر Laravel applications بنانے کے لیے قیمتی علم ہے۔ (دوسری frameworks میں signals کی طرح، انتباہ یہ ہے کہ events implicit، action-at-a-distance رویہ بناتے ہیں جو ٹریس کرنا مشکل ہو سکتا ہے — تو وہ صحیح طریقے سے حقیقی cross-cutting decoupling کے لیے استعمال ہوتے ہیں بجائے تمام post-action logic کے ڈیفالٹ کے، جہاں واضح کوڈ اکثر صاف ہوتا ہے۔)