البرمجة الموجهة نحو الجانب مقابل البرمجة الموجهة نحو الجانبالبرمجة الشيئية

Question

مثل معظم المطورين هنا وفي العالم أجمع، قمت بتطوير أنظمة برمجية باستخدام تقنيات البرمجة الشيئية (OOP) لسنوات عديدة.لذلك عندما قرأت أن البرمجة الموجهة الجوانب (AOP) تعالج العديد من المشكلات التي لا تحلها OOP التقليدية بشكل كامل أو مباشر، أتوقف وأفكر، هل هذا حقيقي؟

لقد قرأت الكثير من المعلومات محاولًا تعلم مفاتيح نموذج AOP هذا وأنا في نفس المكان، لذلك أردت أن أفهم بشكل أفضل فوائده في تطوير التطبيقات في العالم الحقيقي.

هل يملك أحد الإجابة؟

Answer 1

لماذا "ضد"؟إنها ليست "ضد".يمكنك استخدام البرمجة الموجهة نحو الجوانب مع البرمجة الوظيفية، ولكن أيضًا مع البرمجة الكائنية.إنها ليست "مقابل"، بل "برمجة موجهة نحو الجانب". مع البرمجة الشيئية".

بالنسبة لي، AOP هو نوع من "البرمجة الفوقية".كل ما يفعله AOP يمكن تنفيذه بدونه بمجرد إضافة المزيد من التعليمات البرمجية.AOP يوفر عليك فقط كتابة هذا الرمز.

لدى ويكيبيديا أحد أفضل الأمثلة على هذه البرمجة التعريفية.افترض أن لديك فئة رسومية تحتوي على العديد من أساليب "set...()".بعد كل طريقة محددة، تتغير بيانات الرسومات، وبالتالي تتغير الرسومات وبالتالي تحتاج الرسومات إلى التحديث على الشاشة.افترض أنه لإعادة رسم الرسومات يجب عليك استدعاء "Display.update()".النهج الكلاسيكي هو حل هذه المشكلة عن طريق الإضافة المزيد من التعليمات البرمجية.في نهاية كل طريقة محددة تكتبها

void set...(...) {
    :
    :
    Display.update();
}

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

يحل AOP هذه المشكلة دون إضافة الكثير من التعليمات البرمجية، وبدلاً من ذلك يمكنك إضافة جانب:

after() : set() {
   Display.update();
}

وهذا كل شيء!بدلاً من كتابة رمز التحديث بنفسك، ما عليك سوى إخبار النظام أنه بعد الوصول إلى set() pointcut، يجب عليه تشغيل هذا الرمز وسيقوم بتشغيل هذا الرمز.لا حاجة لتحديث 200 طريقة، ولا حاجة للتأكد من أنك لا تنسى إضافة هذا الرمز على طريقة ضبط جديدة.بالإضافة إلى ذلك، تحتاج فقط إلى نقطة:

pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*);

ماذا يعني ذالك؟وهذا يعني أنه إذا تم تسمية الطريقة "set*" (* تعني أن أي اسم قد يتبع بعد المجموعة)، بغض النظر عن ما تُرجعه الطريقة (العلامة النجمية الأولى) أو المعلمات التي تتطلبها (العلامة النجمية الثالثة) و إنها طريقة MyGraphicsClass و هذه الفئة جزء من الحزمة "com.company.*"، فهي عبارة عن set() pointcut.والكود الأول الخاص بنا يقول "بعد عند تشغيل أي طريقة تمثل نقطة محددة، قم بتشغيل التعليمات البرمجية التالية".

هل ترى كيف يحل AOP المشكلة بأناقة هنا؟في الواقع كل ما هو موضح هنا يمكن القيام به في وقت الترجمة.يمكن لمعالج AOP المسبق تعديل المصدر الخاص بك (على سبيل المثال.إضافة Display.update() إلى نهاية كل طريقة set-pointcut) قبل تجميع الفئة نفسها.

ومع ذلك، يوضح هذا المثال أيضًا أحد الجوانب السلبية الكبيرة لـ AOP.تقوم AOP في الواقع بشيء يعتبره العديد من المبرمجين "مكافحة النمط".النمط الدقيق يسمى "العمل على مسافة".

الإجراء على مسافة ما هو مضاد للانهيار (خطأ مشترك معترف به) حيث يختلف السلوك في جزء من البرنامج بشكل كبير بناءً على صعوبة أو مستحيلة في تحديد العمليات في جزء آخر من البرنامج.

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

تحديث

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

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

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

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

Answer 2

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

Answer 3

يوفر البرمجة الموجهة نحو الجوانب طريقة رائعة لتنفيذ الاهتمامات الشاملة مثل التسجيل والأمن.هذه الاهتمامات الشاملة هي أجزاء من المنطق يجب تطبيقها في العديد من الأماكن ولكن في الواقع ليس لها أي علاقة بمنطق الأعمال.

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

1. أصبح منطق كل اهتمام الآن في مكان واحد، بدلاً من أن يكون منتشرًا في جميع أنحاء قاعدة التعليمات البرمجية.

2. تعد الفئات أكثر نظافة لأنها تحتوي فقط على تعليمات برمجية خاصة باهتماماتها الأساسية (أو وظائفها الأساسية) وتم نقل الاهتمامات الثانوية إلى الجوانب.

Answer 4

وأعتقد أن هناك أي إجابة عامة على هذا السؤال ولكن شيء واحد أن يكون لاحظت هو أن اوب لا <م> استبدال OOP لكنه يضيف بعض الميزات التحلل التي تتناول ما يسمى ب <م> طغيان تكوين المهيمن ( 1 ) (أو مخاوف الشاملة).

وكما أنه يساعد بالتأكيد في بعض الحالات طالما كنت في السيطرة على الأدوات واللغات لاستخدامها في مشروع معين، ولكن أيضا يضيف مستوى جديد من التعقيد فيما يتعلق تفاعل الجوانب والحاجة إلى أدوات إضافية مثل < وأ href = "http://www.eclipse.org/ajdt" يختلط = "نوفولو noreferrer"> AJDT لنفهم ما زال البرنامج.

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

Answer 5

وسوف أولا وقبل كل اوب لا يحل محل OOP. اوب يمتد OOP. أفكار وممارسات OOP تبقى ذات الصلة. وجود تصميم الكائن جيد ربما يجعل من الاسهل لتمديده مع الجوانب.

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

وزوجان من اللغات الديناميكية مثل روبي وبيثون ويبني اللغات مثل mixins التي تحل المشاكل نفسها. هذا يبدو مثل الكثير اوب لكن هو أفضل متكامل في اللغة.

والربيع والقلعة واثنين من إطار حقن التبعية الأخرى لديها خيارات لإضافة السلوك إلى الطبقات التي حقن. هذا هو وسيلة للقيام وقت والنسيج وأعتقد أن هذا لديه الكثير من الإمكانيات.

وأنا لا أعتقد أن عليك أن تعلم نموذجا جديدا تماما للاستخدام اوب. أفكار مثيرة للاهتمام ولكن ببطء يجري استيعابها من قبل الأدوات واللغات الموجودة. مجرد البقاء على علم وتجربة هذه الأدوات.

Answer 6

وAOP هو نموذج البرمجة الجديد التعامل مع هذا المفهوم. أحد الجوانب هي كيان برنامج تنفيذ جزء غير وظيفية محددة للتطبيق.

وأعتقد أن هذا المقال هو مكان جيد للبدء مع الجانب برمجة: http://www.jaftalks.com/wp/ index.php / مقدمة إلى المنحى الجانب-البرمجة /

Answer 7

عفوًا يستخدم بشكل رئيسي لتنظيم الخاص بك منطق الأعمال بينما AOP يساعد على تنظيم الخاص بك أشياء غير وظيفية مثل التدقيق والتسجيل وإدارة المعاملات والأمن وما إلى ذلك

بهذه الطريقة يمكنك فصل منطق عملك عن المنطق غير الخيالي الذي يجعل التعليمات البرمجية أكثر وضوحًا.

ميزة Otter هو أنه يمكنك تطبيق النصائح (مثال التدقيق) بشكل متسق للغاية دون تطبيق أي واجهة مما يعطي مرونة كبيرة للتعديل دون لمس منطق الأعمال