"إذا أراد العامل أن يؤدي عمله بشكل جيد، فعليه أولاً أن يشحذ أدواته." - كونفوشيوس، "مختارات كونفوشيوس. لو لينجونج"
الصفحة الأمامية > برمجة > فهم نمط تصميم سلسلة المسؤولية في تطوير الواجهة الخلفية

فهم نمط تصميم سلسلة المسؤولية في تطوير الواجهة الخلفية

تم النشر بتاريخ 2024-11-08
تصفح:709

Understanding the Chain of Responsibility Design Pattern in Backend Development

يعد نمط تصميم سلسلة المسؤولية (CoR) نمطًا سلوكيًا قويًا يمكنه تعزيز تطوير الواجهة الخلفية بشكل كبير. يتيح لك هذا النمط تمرير الطلبات عبر سلسلة من المعالجات، حيث يمكن لكل معالج إما معالجة الطلب أو تمريره إلى المعالج التالي. في هذه المدونة، سنستكشف نمط CoR من منظور الواجهة الخلفية، مع التركيز بشكل خاص على تطبيقه في التحقق من صحة الطلب ومعالجته في خدمة الويب، باستخدام Java كأمثلة لدينا.

متى تستخدم نمط سلسلة المسؤولية

يعد نمط سلسلة المسؤولية مفيدًا بشكل خاص في أنظمة الواجهة الخلفية حيث قد تتطلب الطلبات عدة خطوات للتحقق والمعالجة قبل أن يتم الانتهاء منها. على سبيل المثال، في RESTful API، قد تحتاج الطلبات الواردة إلى التحقق من صحتها من أجل المصادقة والترخيص وتكامل البيانات قبل معالجتها بواسطة منطق العمل الرئيسي. يمكن التعامل مع كل من هذه الاهتمامات بواسطة معالجات مختلفة في السلسلة، مما يسمح بالفصل الواضح بين المسؤوليات والتعليمات البرمجية المعيارية. يعد هذا النمط مفيدًا أيضًا في بنيات البرامج الوسيطة، حيث يمكن لمكونات البرامج الوسيطة المختلفة التعامل مع الطلبات، مما يتيح معالجة مرنة بناءً على معايير محددة.

هيكل نمط سلسلة المسؤولية

يتكون نمط CoR من ثلاثة مكونات رئيسية: المعالج، ومعالجو الخرسانة، والعميل. يحدد

Handler الواجهة للتعامل مع الطلبات ويحتفظ بمرجع إلى المعالج التالي في السلسلة. يقوم كل معالج ملموس بتنفيذ المنطق الخاص بنوع معين من معالجة الطلب، ويقرر ما إذا كان سيتم التعامل مع الطلب أو تمريره إلى المعالج التالي. يرسل العميل الطلبات إلى سلسلة المعالج، ويظل غير مدرك للمعالج الذي سيعالج الطلب في النهاية. يعزز هذا الفصل قابلية الصيانة والمرونة في نظام الواجهة الخلفية.

مثال التنفيذ في جافا

الخطوة 1: تحديد واجهة المعالج

أولاً، سنحدد واجهة RequestHandler التي تتضمن طرقًا لإعداد المعالج التالي وطلبات المعالجة:


فئة مجردة RequestHandler { RequestHandler المحمي nextHandler؛ مجموعة الفراغ العامةNext(RequestHandler nextHandler) { this.nextHandler = nextHandler; } مقبض الفراغ العام (طلب الطلب) { إذا (nextHandler != null) { nextHandler.handleRequest(request); } } }
abstract class RequestHandler {
    protected RequestHandler nextHandler;

    public void setNext(RequestHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}
الخطوة 2: إنشاء معالجات الخرسانة

بعد ذلك، سنقوم بإنشاء فئات معالج ملموسة تعمل على توسيع فئة RequestHandler، كل منها مسؤول عن جانب معين من معالجة الطلب:


يمتد Class AuthenticationHandler إلى RequestHandler { @تجاوز مقبض الفراغ العام (طلب الطلب) { إذا (request.isAuthenticated()) { System.out.println("تم المصادقة بنجاح."); super.handleRequest(request); } آخر { System.out.println("فشلت المصادقة."); request.setValid(false); } } } فئة AuthorizationHandler تمتد RequestHandler { @تجاوز مقبض الفراغ العام (طلب الطلب) { إذا (request.isAuthorized()) { System.out.println("تم التفويض بنجاح."); super.handleRequest(request); } آخر { System.out.println("فشل التفويض."); request.setValid(false); } } } فئة DataValidationHandler تمتد RequestHandler { @تجاوز مقبض الفراغ العام (طلب الطلب) { إذا (request.isDataValid()) { System.out.println("تم التحقق من صحة البيانات بنجاح."); super.handleRequest(request); } آخر { System.out.println("فشل التحقق من صحة البيانات."); request.setValid(false); } } } فئة BusinessLogicHandler تمتد RequestHandler { @تجاوز مقبض الفراغ العام (طلب الطلب) { إذا (request.isValid()) { System.out.println("معالجة منطق الأعمال..."); // قم بتنفيذ منطق العمل الرئيسي هنا } آخر { System.out.println("الطلب غير صالح. لا يمكن معالجة منطق الأعمال."); } } }
abstract class RequestHandler {
    protected RequestHandler nextHandler;

    public void setNext(RequestHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}
الخطوة 3: إعداد السلسلة

الآن، سنقوم بإعداد سلسلة المعالجات بناءً على مسؤولياتهم:


معالج الطلب من الفئة العامة { سلسلة RequestHandler الخاصة؛ معالج الطلب العام () { // إنشاء معالجات RequestHandler authHandler = new AuthenticationHandler(); RequestHandler authzHandler = new AuthorizationHandler(); RequestHandler validationHandler = new DataValidationHandler(); RequestHandler logicHandler = new BusinessLogicHandler(); // قم بإعداد السلسلة authHandler.setNext(authzHandler); authzHandler.setNext(validationHandler); validationHandler.setNext(logicHandler); this.chain = authHandler; // بداية السلسلة } عملية طلب باطلة عامة (طلب طلب) { chain.handleRequest(request); } }
abstract class RequestHandler {
    protected RequestHandler nextHandler;

    public void setNext(RequestHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}
الخطوة 4: رمز العميل

إليك كيفية تفاعل كود العميل مع سلسلة معالجة الطلب:


الطبقة العامة الرئيسية { public static void main(String[] args) { معالج RequestProcessor = جديد RequestProcessor(); // محاكاة طلب صالح طلب صالحطلب = طلب جديد(صحيح، صحيح، صحيح)؛ ProcessRequest(validRequest); // محاكاة طلب غير صالح طلب غير صالح = طلب جديد(صحيح، خطأ، صحيح)؛ ProcessRequest(invalidRequest); } }
abstract class RequestHandler {
    protected RequestHandler nextHandler;

    public void setNext(RequestHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}
فئة الدعم

إليك فئة طلب بسيطة سيتم استخدامها لتغليف بيانات الطلب:


طلب الفصل { مصادقة منطقية خاصة؛ منطقية خاصة معتمدة؛ بيانات منطقية خاصة صالحة؛ منطقية خاصة صالحة = صحيح؛ طلب عام (مصادقة منطقية، إذن منطقي، بيانات منطقية صالحة) { this.authenticated = Authenticated; this.authorized = Authorized; this.dataValid = dataValid; } منطقية عامة تمت المصادقة عليها () { عودة مصادق عليها؛ } المنطقية العامة مسموح بها () { العودة أذن؛ } المنطقية العامة isDataValid() { إرجاع البيانات صالح؛ } القيمة المنطقية العامة صالحة () { عودة صالحة؛ } مجموعة باطلة عامة (منطقية صالحة) { this.valid = valid; } }
abstract class RequestHandler {
    protected RequestHandler nextHandler;

    public void setNext(RequestHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}
شرح الإخراج

عند تشغيل كود العميل، ستلاحظ الإخراج التالي:


تم المصادقة بنجاح. تم التفويض بنجاح. تم التحقق من صحة البيانات بنجاح. معالجة منطق الأعمال... تمت المصادقة بنجاح. فشل التفويض. الطلب غير صالح. لا يمكن معالجة منطق الأعمال.
abstract class RequestHandler {
    protected RequestHandler nextHandler;

    public void setNext(RequestHandler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public void handleRequest(Request request) {
        if (nextHandler != null) {
            nextHandler.handleRequest(request);
        }
    }
}
    تمت معالجة الطلب الأول بنجاح من خلال جميع المعالجات، مما يوضح أن السلسلة بأكملها تعمل على النحو المنشود.
  • فشل الطلب الثاني أثناء خطوة التفويض، مما يؤدي إلى إيقاف المزيد من المعالجة ومنع الطلبات غير الصالحة من الوصول إلى منطق الأعمال.
فوائد نمط سلسلة المسؤولية

  1. فصل الاهتمامات : يتحمل كل معالج مسؤولية مميزة، مما يجعل الكود أسهل في الفهم والصيانة. يسمح هذا الفصل للفرق بالتركيز على جوانب محددة من معالجة الطلب دون القلق بشأن سير العمل بأكمله.

  2. التعامل المرن مع الطلبات : يمكن إضافة المعالجات أو إزالتها دون تغيير المنطق الحالي، مما يسمح بالتكيف بسهولة مع المتطلبات الجديدة أو التغييرات في قواعد العمل. تدعم هذه الوحدة ممارسات التطوير الرشيقة.

  3. تحسين قابلية الصيانة : الطبيعة المنفصلة للمعالجات تعني أن التغييرات في معالج واحد (مثل تحديث منطق التحقق من الصحة) لا تؤثر على المعالجات الأخرى، مما يقلل من خطر إدخال الأخطاء في النظام.

  4. اختبار أسهل

    : يمكن اختبار المعالجات الفردية بشكل منفصل، مما يبسط عملية الاختبار. وهذا يسمح باختبارات الوحدة المستهدفة وتصحيح الأخطاء بشكل أكثر وضوحًا لخطوات معالجة طلب محددة.

  5. العيوب

  1. عبء الأداء

    : قد تؤدي سلسلة طويلة من المعالجات إلى زمن الوصول، خاصة إذا كانت هناك حاجة إلى إجراء العديد من عمليات التحقق بشكل تسلسلي. في التطبيقات ذات الأداء الحرج، يمكن أن يصبح هذا مصدر قلق.

  2. التعقيد في التحكم في التدفق

    : في حين أن النمط يبسط مسؤوليات المعالج الفردي، إلا أنه يمكن أن يؤدي إلى تعقيد التدفق الإجمالي لمعالجة الطلب. قد يتطلب فهم كيفية معالجة الطلبات من خلال معالجات متعددة وثائق إضافية وجهدًا لأعضاء الفريق الجدد.

  3. خاتمة

نمط

سلسلة المسؤولية

هو نمط تصميم فعال في تطوير الواجهة الخلفية الذي يعزز معالجة الطلب من خلال تعزيز الفصل بين الاهتمامات والمرونة وقابلية الصيانة. من خلال تنفيذ هذا النمط للتحقق من صحة الطلب ومعالجته، يمكن للمطورين إنشاء أنظمة قوية وقابلة للتطوير قادرة على التعامل مع المتطلبات المختلفة بكفاءة. سواء كان ذلك في واجهة برمجة تطبيقات RESTful، أو معالجة البرامج الوسيطة، أو تطبيقات الواجهة الخلفية الأخرى، فإن تبني نمط CoR يمكن أن يؤدي إلى تعليمات برمجية أكثر وضوحًا وتصميمًا معماريًا محسّنًا، مما يؤدي في النهاية إلى حلول برمجية أكثر موثوقية وقابلة للصيانة.

بيان الافراج تم إعادة نشر هذه المقالة على: https://dev.to/syridit118/understanding-the-chain-of-responsibility-design-pattern-in-backend-development-p2f?1 إذا كان هناك أي انتهاك، يرجى الاتصال بـ Study_golang@163 .com لحذفه
أحدث البرنامج التعليمي أكثر>

تنصل: جميع الموارد المقدمة هي جزئيًا من الإنترنت. إذا كان هناك أي انتهاك لحقوق الطبع والنشر الخاصة بك أو الحقوق والمصالح الأخرى، فيرجى توضيح الأسباب التفصيلية وتقديم دليل على حقوق الطبع والنشر أو الحقوق والمصالح ثم إرسالها إلى البريد الإلكتروني: [email protected]. سوف نتعامل مع الأمر لك في أقرب وقت ممكن.

Copyright© 2022 湘ICP备2022001581号-3