1. Chain of Responsibility Pattern کیا ہے
Chain of Responsibility Pattern ایک بارویہ ڈیزائن پیٹرن ہے جو مختلف آبائیں کو موافق موقع دینے کا موقع فراہم کرتا ہے تاکہ درخواست کو حاصل کرنے والے اور منتقل کرنے والے کو علیحدہ کردیں۔ ہر منتقل کنندہ میں ایک دوسرے دستہ ور کا حوالہ ہوتا ہے، اور اگر یہ درخواست سنبھال نہیں سکتا، تو یہ درخواست اگلے منتقل کنندہ تک فورورڈ کرتا ہے جب تک کہ درخواست سنبھالی نہیں جاتی یا زنجیر کا اختتام نہیں ہو جاتا۔
2. Chain of Responsibility Pattern کی خصوصیات اور فوائد
Chain of Responsibility Pattern کی خصوصیات اور فوائد مندرجہ ذیل ہیں:
- موافقت کرنے والے اور منتقل کرنے والے کا فراق: بھیجنے والے کو درخواست کو کس نے دباؤ لیا ہے، اسکا خیال رکھنے کی ضرورت نہیں ہوتی ہے، اور نہ ہی یہ ضرورت ہوتی ہے کہ زنجیر میں مخصوص ہینڈلر کون سنبھال رہا ہے۔
- استحکام: یہ زنجیر میں ہینڈلر کو ڈائنامک طریقے سے شامل، ہٹائیں، یا دوبارہ ترتیب دیں بغیر سینڈر اور ریسیور کو ترتیب نہیں دینے کی اجازت دیتا ہے۔
- استدلال کرنے کی صلاحیت: نئے خصوصی ہینڈلر کے اضافے سے ذمہ داری کا زیندہ زنجیر کرنا آسان ہوتا ہے۔
- اکیلا ذمہ داری کا مسئلہ: ہر مخصوص ہینڈلر کو صرف اپنی ذمہ داری کے بارے میں خیال رکھنے کی ضرورت ہوتی ہے۔
- تشکیل: ہینڈلر کی زنجیر کو ضرورت کے مطابق ترتیب دینے کی اجازت دینے سے، مختلف درخواستوں کو مختلف ہینڈلر کی زنجیر دی جا سکتی ہے۔
3. Chain of Responsibility Pattern کی عملی استعمال کی مثالیں
Chain of Responsibility Pattern کے کئی عملی استعمال ہوتے ہیں، جیسے:
- ویب ایپلیکیشن میں درخواست سنبھالنا: اسے مختلف قسم کی درخواستوں کو سنبھالنے کے لئے استعمال کیا جا سکتا ہے، جیسے پہچان تصدیق، لاگنگ، اور اجازت کی تصدیق۔
- خطا سنبھالی: یہ غلطیوں کو سنبھالنے کے لئے استعمال کیا جا سکتا ہے، جہاں ہر ہینڈلر کو کسی خاص قسم کی غلطی کو سنبھالنے کی ذمہ داری ہوتی ہے اور ضرورت پڑنے پر غلطی کو اگلا ہینڈلر تک فورورڈ کرنی ہوتی ہے۔
- تقریبی سنبھالی: اسے مختلف قسم کی تقریبیوں کو سنبھالنے کے لئے استعمال کیا جا سکتا ہے، جیسے صارف کلک کی واقعات، نیٹ ورک کی درخواست واقعات، وغیرہ۔
4. Golang میں Chain of Responsibility Pattern کی تنظیم
4.1 UML Class Diagram
4.2 مثال کی تعاریف
UML کلاس کی تشریح میں، ہم نے ایک انتہائی ہینڈلر (Handler) اور دو مضمون ہینڈلر (ConcreteHandler1 اور ConcreteHandler2) کی تعریف کی ہے۔ کلائنٹ (Client) ہینڈلر کے handleRequest ترکیب کو بلاتے ہوئے درخواست کو شروع کرتا ہے۔
4.3 تنظیم کا مرحلہ 1: انتہائی ہینڈلر انٹرفیس کی تعریف
type Handler interface {
HandleRequest(request Request) error
SetNext(handler Handler)
}
type Request interface {
Condition bool
}
انتہائی ہینڈلر انٹرفیس کو درخواست کی پروسیسنگ اور اگلے ہینڈلر کی تنظیم کے لئے handleRequest اور SetNext تراکیب کی تعریف کرتا ہے۔
4.4 تنظیم کا مرحلہ 2: مضمون ہینڈلر کلاسز کی تنظیم
type ConcreteHandler1 struct {
next Handler
}
func (h *ConcreteHandler1) HandleRequest(request Request) error {
// Logic for handling the request
if request.Condition {
// Code for handling the request
return nil
} else {
if h.next != nil {
return h.next.HandleRequest(request)
}
return errors.New("No handler found")
}
}
func (h *ConcreteHandler1) SetNext(handler Handler) {
h.next = handler
}
type ConcreteHandler2 struct {
next Handler
}
func (h *ConcreteHandler2) HandleRequest(request Request) error {
// Logic for handling the request
if request.Condition {
// Code for handling the request
return nil
} else {
if h.next != nil {
return h.next.HandleRequest(request)
}
return errors.New("No handler found")
}
}
func (h *ConcreteHandler2) SetNext(handler Handler) {
h.next = handler
}
مضمون ہینڈلر کلاسز نے انتہائی ہینڈلر انٹرفیس کو تنظیم کیا ہے اور ہینڈلر کی handleRequest اور SetNext تراکیب کو اووررائی کیا ہے۔
4.5 تنظیم کا مرحلہ 3: Chain of Responsibility کی تشکیل
handler1 := &ConcreteHandler1{}
handler2 := &ConcreteHandler2{}
handler1.SetNext(handler2)
مضمون ہینڈلر کو یقینی بنا کر اور اگلا ہینڈلر تنظیم کرتے ہوئے، چین آف رسپانسبلٹی کی زنجیر بنائی جاتی ہے۔
4.6 تنظیم کا مرحلہ 4: کلائنٹ کوڈ
func main() {
handler := &ConcreteHandler1{}
// Chain of Responsibility کی بنائی
handler.SetNext(&ConcreteHandler2{})
// درخواست بھیجنا
handler.HandleRequest(Request{Condition: true})
}
کلائنٹ کوڈ میں، ایک مضمون ہینڈلر کو یقینی بنایا جاتا ہے، اگلا ہینڈلر تنظیم کیا جاتا ہے، اور پھر handleRequest ترکیب کو بلایا جاتا ہے تاکہ ایک درخواست بھیجی جا سکے۔