فهم الوكيل الديناميكي في جافا في عشر دقائق

إذا كانت فئة الوكيل موجودة بالفعل قبل تشغيل البرنامج ، فإن طريقة الوكيل هذه تسمى الوكيل الثابت. في هذه الحالة ، يتم تعريف فئة الوكيل عادة في كود Java. عادة ، تنفذ فئة الوكيل وفئة المفوض في الوكيل الثابت نفس الواجهة أو مستمدة من نفس الفئة الأصل.

1. نظرة عامة
1. ما هو الوكيل
نعلم جميعًا أن وكلاء WeChat يقومون ببساطة ببيع البضائع نيابة عن الشركات المصنعة ، وأن الشركة المصنعة "الموكلون" لبيع البضائع لهم. فيما يتعلق بالوكلاء التجاريين في WeChat ، أولاً وقبل كل شيء ، عندما نشتري أشياء منهم ، عادةً ما لا نعرف من هي الشركة المصنعة ، أي أن "المفوض" غير مرئي لنا ؛ ثانياً ، يستهدف وكلاء الأعمال في WeChat الأشخاص بشكل أساسي في دائرة الأصدقاء كعملائهم ، وهو ما يعادل "مرشح" مجموعة العملاء للمصنع. نحن كذلك تجريد وكيل الأعمال الصغيرة والشركة المصنعة. يمكن استخلاص السابق كصف وكيل ، ويمكن استخلاص الأخير كصف مندوب (فئة الوكيل). باستخدام وكيل ، عادة ما تكون هناك مزايزان ويمكن أن تتوافق مع خصائص عامل الأعمال الصغيرة التي ذكرناها:
ميزة 1: يمكن أن تخفي تنفيذ فئة المندوب ؛
الميزة 2: يمكن أن تحقق فصلها بين العميل وفئة المندوب ، ويمكنها القيام ببعض المعالجة الإضافية دون تعديل رمز فئة المندوب.
2. وكيل ثابت
إذا كانت فئة الوكيل موجودة بالفعل قبل تشغيل البرنامج ، فإن طريقة الوكيل هذه تسمى الوكيل الثابت. في هذه الحالة ، يتم تعريف فئة الوكيل عادة في كود Java. عادة ، تنفذ فئة الوكيل وفئة المفوض في الوكيل الثابت نفس الواجهة أو مستمدة من نفس الفئة الأصل. أدناه نستخدم فئة البائعين لتمثيل الشركة المصنعة وفئة Businessagent لتمثيل وكيل الأعمال الصغيرة لتقديم التنفيذ البسيط للعوامل الثابتة. يقوم كل من فئة التفويض وفئة الوكيل بتنفيذ واجهة البيع. تعريف واجهة البيع كما يلي:

 الواجهة العامة بيع {void sell () ؛ باطلة ad () ؛ } تعريف فئة البائعين كما يلي: يقوم بائع الفئة العامة ببيع {public void sell () {system.out.println ("in sell method") ؛ } public void ad () {system ، out.println ("ad method")}}

إن تعريف Proxy Class Businessagent كما يلي:

 يقوم بائع الفئة العامة ببيع {public void sell () {system.out.println ("in sell method") ؛ } public void ad () {system ، out.println ("ad method")}}

من تعريف فئة BusinessAgent ، يمكننا أن نفهم أنه يمكن تنفيذ العوامل الثابتة من خلال التجميع ، بحيث يمكن لفئة الوكيل الإشارة إلى فئة المفوض.
دعنا ننظر في هذا المطلب أدناه: أضف وظيفة تصفية إلى فئة البائعين وبيع البضائع فقط لطلاب الجامعات. من خلال الوكيل الثابت ، يمكننا تحقيق ذلك دون تعديل رمز فئة البائع. نحتاج فقط إلى إضافة حكم إلى طريقة البيع في فئة Businessagent ويمكن أن يكون كما يلي:

 أدوات Public Class BusinessAgent Sell {... public void sell () {if (isCollegestudent ()) {Pendor.Sell () ؛ }} ...}

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

2. العامل الديناميكي
1. ما هو الوكيل الديناميكي
تسمى طريقة الوكيل التي أنشأتها فئة الوكيل عند تشغيل البرنامج وكيل ديناميكي. أي في هذه الحالة ، لم يتم تعريف فئة الوكيل في رمز Java ، ولكن يتم إنشاؤها ديناميكيًا في وقت التشغيل بناءً على "تعليماتنا" في رمز Java. بالمقارنة مع الوكيل الثابت ، فإن ميزة الوكيل الديناميكي هي أنه يمكنه بسهولة التعامل مع وظائف فئة الوكيل بشكل موحد دون تعديل وظائف لكل فئة وكيل. هذا أكثر تجريدًا. دعنا نجمع بين مثال لتقديم كيف تنعكس مزايا الوكيل الديناميكي.
الآن ، لنفترض أننا نريد تنفيذ المتطلبات: الإخراج "قبل" قبل تنفيذ الطريقة في فئة المندوبين ، والإخراج "بعد" بعد التنفيذ. سنقدم فئة البائعين كصف مندوب في المثال أعلاه ، وفئة BusinessAgent كفئة الوكيل. أولاً ، دعنا نستخدم وكيلًا ثابتًا لتحقيق هذا المطلب. الرمز ذي الصلة كما يلي:

 أدوات Businessagent من الطبقة العامة بيع {Private Pendor Mvendor ؛ BusinessAgent العامة (بائع البائع) {this.mvendor = البائع ؛ } public void sell () {system.out.println ("ins") ؛ mvendor.sell () ؛ System.out.println ("بعد") ؛ } public void ad () {system.out.println ("قبل") ؛ mvendor.ad () ؛ System.out.println ("بعد") ؛ }}

من الكود أعلاه ، يمكننا أن نفهم أن تنفيذ احتياجاتنا من خلال الوكيل الثابت يتطلب منا إضافة المنطق المقابل إلى كل طريقة. لا يوجد سوى طريقتين هنا ، وبالتالي فإن عبء العمل ليس كبيرًا. ماذا لو كانت واجهة البيع تحتوي على مئات الطرق؟ في هذا الوقت ، سيقوم استخدام الوكيل الثابت بكتابة الكثير من التعليمات البرمجية الزائدة. باستخدام الوكيل الديناميكي ، يمكننا تقديم "إشارة موحدة" لمعالجة أساليب جميع فئات البروكسي بشكل موحد دون تعديل كل طريقة واحدة تلو الأخرى. دعونا نقدم كيفية استخدام الوكيل الديناميكي لتنفيذ احتياجاتنا.
2. استخدم الوكيل الديناميكي
(1) عند استخدام الوكيل الديناميكي في واجهة InvocationHandler ، نحتاج إلى تحديد فئة وسيطة موجودة بين فئة الوكيل وفئة المندوب. مطلوب هذه الفئة الوسيطة لتنفيذ واجهة InvocationHandler. تعريف هذه الواجهة كما يلي:

 الواجهة العامة invocationHandler {Object Invoke (Proxy Object ، method method ، Object [] args) ؛ }

من الاسم ، يمكننا أن نعرف أن فئة الوساطة التي تنفذ هذه الواجهة تستخدم كـ "معالج المكالمات". عندما نسمي طريقة كائن فئة الوكيل ، سيتم إعادة توجيه هذه "المكالمة" إلى طريقة الاستدعاء. يتم تمرير كائن فئة الوكيل كمعلمة وكيل. تحدد طريقة المعلمة الطريقة التي نسميها فئة الوكيل. ARGS هو معلمة هذه الطريقة. وبهذه الطريقة ، ستصبح مكالماتنا إلى جميع الطرق في فئة الوكيل مكالمات للاستدعاء ، حتى نتمكن من إضافة منطق معالجة موحد إلى طريقة الاستدعاء (أو الطرق المختلفة لفئة الوكيل يمكن معالجتها وفقًا لمعلمات الطريقة). لذلك ، نحتاج فقط إلى الإخراج "قبل" في تنفيذ طريقة الاستدعاء لفئة الوساطة ، ثم استدعاء طريقة الاستدعاء لفئة المندوبين ، ثم الإخراج "بعد". دعنا ننفذها خطوة بخطوة.
(2) بموجب طريقة الوكيل الديناميكي لفئة المفوض ، يجب على فئة المندوب تنفيذ واجهة معينة. هنا ننفذ واجهة البيع. تعريف فئة البائعين كما يلي:

 يقوم بائع الفئة العامة ببيع {public void sell () {system.out.println ("in sell method") ؛ } public void ad () {system ، out.println ("ad method")}}

(3) فئة الوساطة كما هو مذكور أعلاه ، يجب أن تنفذ فئة الوساطة واجهة InvocationHandler ، حيث أن معالج المكالمات "اعتراض" على أساليب فئة الوكيل. تعريف الفئة الوسيطة كما يلي:

 الطبقة العامة DynamicProxy تنفذ invocationHandler {private object obj ؛ // OBJ هو كائن فئة مندوب ؛ DynamicProxy (Object obj) {this.obj = obj ؛ } Override public object invoke (Proxy Object ، method method ، object [] args) remable {system.out.println ("ins") ؛ نتيجة الكائن = method.invoke (obj ، args) ؛ System.out.println ("بعد") ؛ نتيجة العودة }}

من الكود أعلاه ، يمكننا أن نرى أن الفئة الوسيطة تحمل مرجع كائن مندوب ، ويتم استدعاء الطريقة المقابلة لكائن المفوض في طريقة Invoke (السطر 11). هل تعتقد أنه يبدو مألوفًا عندما ترى هذا؟ عقد مرجع كائن مندوب من خلال طريقة التجميع ، في النهاية تحويل جميع المكالمات الخارجية لاستدعاء مكالمات إلى كائن المندوب. أليس هذه طريقة تنفيذ للوكيل الثابت الذي قدمناه أعلاه؟ في الواقع ، تشكل الطبقة الوسيطة وفئة المندوب علاقة وكيل ثابت. في هذه العلاقة ، تعد الفئة الوسيطة فئة وكيل ، وفئة المفوض هي فئة تفويض ؛ تشكل فئة الوكيل والفئة الوسيطة أيضًا علاقة وكيل ثابت. في هذه العلاقة ، فإن الطبقة الوسيطة هي فئة تفويض وفئة الوكيل هي فئة وكيل. بمعنى آخر ، تتكون علاقة الوكيل الديناميكي من مجموعتين من علاقات الوكيل الثابتة ، وهو مبدأ الوكيل الديناميكي. دعونا نقدم كيفية "إرشاد" توليد فصول الوكيل ديناميكيًا.
(4) الوكيل الديناميكي من فئة الوكيل الديناميكي فئة الوكيل الرموز ذات الصلة هي كما يلي:

 الفئة العامة الرئيسية {public static void main (string [] args) {// إنشاء مثيل من فئة الوساطة dynamicproxy inter = new DynamicProxy (New Pendor ()) ؛ // إضافة هذه الجملة ، ستقوم بإنشاء ملف $ proxy0.class ، وهو نظام ملفات فئة الوكيل الذي تم إنشاؤه ديناميكيًا. // الحصول على مثيل فئة الوكيل بيع بيع بيع = (بيع) (proxy.newproxyinstance (sell.class.getClassloader () ، فئة جديدة [] {sell.class} ، inter)) ؛ // استدعاء طريقة فئة الوكيل من خلال كائن فئة الوكيل سوف ينتقل فعليًا إلى طريقة الاستدعاء لاستدعاء Sell.sell () ؛ sell.ad () ؛ }}

في الكود أعلاه ، نسمي طريقة NewProxyInstance لفئة الوكيل للحصول على مثيل فئة وكيل. تنفذ فئة الوكيل هذه الواجهة التي حددناها وستقوم بتوزيع مكالمات الطريقة على معالج الاتصال المحدد. إن إعلان هذه الطريقة على النحو التالي:
انسخ الرمز على النحو التالي: كائن ثابت عام NewProxyInstance (Loader ClassLoader ، فئة <؟> [] واجهات ، invocationHandler H) يلقي alfictalargumentexception
المعلمات الثلاثة للطريقة هي كما يلي:
Loader: يحدد مصنف فئة الوكيل ؛
واجهات: قائمة الواجهات التي تنفذها فئة الوكيل
H: اتصل بالمعالج ، أي أن مثيل الفصل الذي حددناه أعلاه ينفذ واجهة InvocationHandler ، دعنا نديرها لمعرفة ما إذا كان الوكيل الديناميكي لدينا يمكن أن يعمل بشكل صحيح. الإخراج الذي أديره هنا هو:

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

ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.