شرح مفصل للوكيل الثابت الربيعي ورمز الوكيل الديناميكي

النقاط الرئيسية لهذا القسم:

الوكيل الثابت جافا
JDK Dynamic Agent

1 مشاكل مواجهتها في أفكار التصميم الموجهة للكائنات

في برمجة OOP التقليدية ، تكون الكائنات جوهرية ويتم تشكيل وظيفة البرنامج الكاملة من خلال التعاون بين الكائنات. نظرًا لأن الكائنات يمكن أن تورث ، يمكننا تجريد سمات مع نفس الوظائف أو نفس الخصائص في نظام بنية فئة هرمية بوضوح. مع التوسع المستمر لمواصفات البرمجيات ، أصبح قسم العمل الأكثر احترافًا أكثر فأكثر ، وقد كشف العدد المتزايد لممارسات تطبيق OOP أيضًا عن بعض المشكلات التي لا يمكن لـ OOP حلها جيدًا.

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

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

التسجيل موجود في كل مكان في الكود - انظر أولاً إلى مثال:

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

 // راجع المقالة "log4j مقدمة" لـ log4j import org.apache.log4j.logger ؛ public class person {private logger logger = logger.getLogger (person.class) ؛ public void sleep () Date () ؛} public void eating () {logger.info ("بدء التنفيذ وقت:" + New Date ()) ؛ DATE ()

سؤال: ما هي العيوب؟

يربك مسؤوليات طريقة العمل نفسها

عبء عمل الصيانة ضخم

2 الحل 1

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

الغرض من L هو فصل رمز العمل تمامًا عن رمز السجل وتحقيق اقتران فضفاض.

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

تنفيذ الوكيل الثابت

1) تحديد الواجهة:

 الواجهة العامة Iperson {public Abstract Void Sleep () ؛ Public Abstract Void Eat () ؛}

2) فئة الوكيل

 شخص الطبقة العامة ينفذ iperson {public void sleep () {system.out.println ("sleeping") ؛} public void eating () {system.out.println ("EATE") ؛}}

3) فئة الوكيل

 استيراد org.apache.log4j.logger ؛ الطبقة العامة personproxy تنفذ iperson {private iperson person ؛ private logger logger = logger.getLogger (personproxy.class) ؛ public personproxy (eRnage extrening) {this.person = person ؛ DATE () ") ؛ person.eating () ؛ logger.info (" "وقت التنفيذ وقت نهاية التنفيذ:" + تاريخ جديد () ") ؛} public void sleep () {logger.info (" بدء التنفيذ وقت التنفيذ: " + تاريخ جديد ()")

4) فئة الاختبار

 package com.aptech.aop2 ؛ public persontest {public static void main (string [] args) {iperson proxy = new personproxy (new person ()) ؛ proxy.eating () ؛ proxy.sleep () ؛}}

عيوب الوكيل الثابت:

يمكن أن تخدم واجهة الوكيل نوعًا واحدًا فقط من الكائنات. إنه ببساطة غير كفء بالنسبة للمشاريع الأكبر قليلاً.

3 حل 2-وكيل الديناميك

InvocationHandler: يجب أن تنفذ كل فئة من فئة الوكيل الديناميكي واجهة InvocationHandler ، وترتبط كل مثيل من فئة الوكيل بالمعالج. عندما نسمي طريقة من خلال كائن الوكيل ، سيتم إعادة توجيه دعوة هذه الطريقة إلى طريقة Invoke لواجهة InvocationHandler للاتصال.

بعد JDK1.3 ، تمت إضافة وظيفة وكيل ديناميكي يمكن أن تساعد في التطوير. ليست هناك حاجة لكتابة كائنات وكيل محددة لكائنات وطرق محددة. يمكن أن يؤدي استخدام البرامج الديناميكية إلى جعل المعالج يخدم كل كائن.
يجب أن ينفذ تصميم فئة المعالج واجهة java.lang.reflect.invocationHandler.
يمكن للوكالة الديناميكية التي يتم تنفيذها من خلال واجهة InvocationHandler أن تتكيد فئة تنفيذ الواجهة فقط.

تنفيذ الوكيل الديناميكي

1) معالج

 الطبقة العامة dynaproxyhandler تنفذ invocationHandler {private logger logger = logger.getLogger (dynaproxyhandler.class) ؛ هدف الكائن الخاص ؛ // كائن بالوكالة void void settarget (target) {this.target = target ؛} الكائن العام Date ()) ؛ نتيجة الكائن = method.invoke (الهدف ، args) ؛ logger.info ("وقت الانتهاء الوقت:" + تاريخ جديد ()) ؛ نتيجة الإرجاع ؛ // نتيجة تنفيذ طريقة الإرجاع}}

2) مصنع لوكيل الإنتاج

 استيراد java.lang.reflect.proxy ؛ الطبقة العامة dynaproxyfactory {// obj هو كائن ثابت للكائن الثابت getProxy (كائن obj) {dynaproxyhandler handler = new DynaproxyHandler () ؛ handler.settarget (obj) ؛ proxy.newproxyinstance (obj.getClass (). getClassloader () ، obj.getclass ().

3) فئة الاختبار

 Public Class Persontest {public static void main (string [] args) {iperson person = (iperson) dynaproxyfactory.getproxy (new person ()) ؛ // إرجاع فئة الوكيل ، يتم إنشاء فئة الوكيل ديناميكيًا بواسطة JVM في الذاكرة. تنفذ هذه الفئة جميع واجهات (جميع الطرق) من صفيف الواجهة الواردة.

لخص

ما سبق هو كل التفسير التفصيلي للوكيل الثابت الربيعي ورمز الوكيل الديناميكي في هذه المقالة. آمل أن يكون ذلك مفيدًا للجميع. يمكن للأصدقاء المهتمين الاستمرار في الرجوع إلى هذا الموقع:

التكوين الشائع والتحليل فئة وصف الربيع

ينفذ اعتراض springmvc علامة واحدة

تنفيذ برمجة Java لـ SpringMVC مثال تسجيل الدخول البسيط

إذا كانت هناك أي أوجه قصور ، فيرجى ترك رسالة لإشارةها. شكرا لك يا أصدقائك لدعمكم لهذا الموقع!