AOP مقابل الميزات

البرمجة الموجهة نحو الجانب (AOP) هي نموذج برمجة مشهور إلى حد ما. تشرح مقالة ويكيبيديا الدافع وراء هذا النهج.



AOP هي أداة ممتازة للمفاهيم العالمية ، مثل: logging ، والتي ، مباشرة ، لا تؤثر على منطق الكود.

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

@RequireRole(Role.Admin) // clearly visible aspect fun updateUserPermissions(…) { // logic here } 

ومع ذلك ، من حيث قابلية القراءة ، فإنه لا يختلف كثيرًا عن النهج الوظيفي ، وذلك باستخدام طريقة requireRole بدلاً من التعليق التوضيحي.

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

أيضا:

1. في المستقبل ، سوف نعود إلى مفهوم وظائف الرتب العليا

2. يصادف المقال كلمة جانب ، وهي اللغة الإنجليزية والمفهوم في الجانب AOP

 fun updateUserPermissions(…) { requireRole(Role.Admin) // throws SecurityException // logic here } 

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

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

في Kotlin ، بدلاً من نهج معاملة يشبه Java باستخدام AOP وشروح مثل هذه:

 @Transactional fun updateUserPermissions(…) { // logic here } 

كما أنه قابل للقراءة ويبدو نظيفًا عند إعادة كتابته بدون تعليقات توضيحية ، مع اتباع منهج وظيفي.

 fun updateUserPermissions(…) = transactional { // logic here } 

تتمثل ميزة هذا الأسلوب في أنه يمكنك دائمًا الضغط على Ctrl / Cmd + انقر على إعلان وظيفة المعاملات في IDE الخاص بك ومعرفة ما يفعله بالضبط على الفور. وهو عادة ما يكون غير ممكن مع أي من أطر AOP شائعة الاستخدام. حتى عندما يتم توفير التنقل إلى رمز العرض الجانبي باستخدام البرنامج المساعد IDE ، يتطلب فك تشفير منطقه معرفة API و / أو اصطلاحات متعددة الوظائف منفصلة.

لسوء الحظ ، هناك مشاكل في توسيع نطاق الاستعاضة عن تعليقات AOP في Kotlin. بالنسبة للحالة التي يتم فيها تطبيق العديد من الجوانب على نفس الوظيفة ، مع تراكم الأقواس البادئة والمسافة البادئة:

 fun updateUserPermissions(…) = logged { transactional { // logic here } } 

الحل البديل هو إنشاء دالة ذات ترتيب أعلى للاحتفاظ برمز مقبول عند تطبيق جوانب متعددة:

 fun updateUserPermissions(…) = loggedTransactional { // logic here } 

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

 fun updateUserPermissions(params: Params) = logged("updateUserPermissions($params)") { // logic here } 

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

في الختام ، أود أن أقول إن زيادة تحسين التجريدات الوظيفية لتوفير بديل أفضل عن AOP يمكن أن يكون ناقلًا واعداً للتطور المستقبلي للغة Kotlin. عادةً ما تكون أطر عمل AOP المستندة إلى Java خاصة بـ JVM ويُنظر إليها على أنها سحرية ، في حين أن التجريدات الوظيفية لـ Kotlin هي بالفعل منصة مشتركة وشفافة للمستخدم.

ملاحظة المترجم :
1. المادة على المتوسطة (المهندس) .
2. مؤلف المقال الأصلي هو رومان إليزاروف ( قائد فريق JetBrains ، الذي يعمل على تحليلات وكوتلين Kotlin ، البرمجة الرياضية / ICPC ، التزامن والخوارزميات ، الرياضيات / التمويل الكمي ؛ سابقًا Devexperts). على هبر إليزاروف