AOP... هل يجب أن أتخلص من OOP؟
https://stackoverflow.com/questions/1325385
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد قمت بتصفح الوثائق الموجودة على الإنترنت، وقرأت مدخلات الويكي، والمشاركات والمدونات، ولكنني مازلت في حيرة من أمري.
- ما هو باختصار، الجانب برمجة ?
- هل هي ببساطة أفضل من البرمجة الشيئية؟هل يجب أن أتخلى عن OOP؟
- إذا لم يكن الأمر كذلك، فكيف أعرف متى أستخدم أحدهما أو الآخر؟ما هي الاختلافات الرئيسية بين الاثنين؟
- هل يمكنني إعادة دمج أحدهما في الآخر؟
لقد كنت دائمًا رجل OO وأريد أن أعرف ما إذا كنت بحاجة إلى ارتكاب الخيانة.
بجدية، سأبدأ مشروعًا جديدًا قريبًا وأريد أن أقوم بالاختيارات الصحيحة في البداية.
المحلول
ما هي باختصار البرمجة الموجهة نحو الجوانب؟
باختصار، AOP هي القدرة على إدخال الإجراءات في التدفق النموذجي لبرنامج آخر، بشكل غير مخفي.يتيح لك التقاط عمليات إنشاء مثيل للفصل الدراسي واستدعاءات الأساليب والواجبات وما إلى ذلك.
هل هي ببساطة أفضل من البرمجة الشيئية؟هل يجب أن أتخلى عن OOP؟
لا و لا.إنه يعمل مع أي بيئة برمجة تدعمه.(أنظر فوق).
إذا لم يكن الأمر كذلك، فكيف أعرف متى أستخدم أحدهما أو الآخر؟ما هي الاختلافات الرئيسية بين الاثنين؟
يمكنك استخدام AOP، بشكل عام، عندما تريد تنفيذ نوع من الإجراءات على مئات الفئات، دون التلاعب بالفئات نفسها.الأمثلة النموذجية هي الأمان (تفويض الحق في استدعاء الطريقة/الفئة المحددة) أو التسجيل.لكن من خلال تجربتي، لا أستخدمه لهذا الغرض.(أنا لا أستخدمه على الإطلاق، بصراحة).
كما هو مذكور أعلاه، فإن الفرق الرئيسي غير موجود حقًا، حيث لا يمكن مقارنتهما.ولكن، لنفترض أنك تريد تنفيذ التسجيل "بشكل طبيعي"، ما عليك سوى الاتصال بالمسجل في النقاط المناسبة:
log.write("hello");
لكن باستخدام AOP، يمكنك إنشاء "جانب" يرتبط بكل استدعاء للطريقة، وتسجيل "استدعاء الطريقة ب".النقطة المهمة هي أنه في AOP فإنك تقترب أكثر من "البندقية":يمكنك إرفاق كل شيء، أو مجرد مجموعة فرعية صغيرة.يعد إضافة التسجيل يدويًا أفضل بشكل عام.
هل يمكنني إعادة دمج أحدهما في الآخر؟
ليست ذات صلة حقًا، راجع الإجابات الأخرى.مرة أخرى، مع الأمان، يمكنك التبديل إلى نموذج AOP من نموذج OOP النموذجي this.IsAllowed() إلى شيء مثل if(callingMethod.HasAttribute(foo)){ المسموح = صحيح؛}
نأمل أن تكون هذه الإجابات مفيدة.اسمحوا لي أن أعرف إذا كنت تريد مني التوسع أكثر.
نصائح أخرى
لا، يعمل AOP OOP، بدلا من محلها. توفر AOP و OOP أنواعا مختلفة من "الغراء" لمساعدتك في الجمع بين السلوكيات. OOP، بالطبع، يتيح لك الجمع بين السلوك من خلال الميراث والتركيب، إلخ. AOP من ناحية أخرى يتيح لك إضافة سلوك إلى العنوان اهتمامات مشتركة عن طريق اعتراض تخفيضات نقطة حيث يتم تشغيل التعليمات البرمجية الجديدة قبل أو بعد الأساليب المختارة للفئات المختارة.
بعض الأمثلة الشائعة لمخاوف القطع المتقاطعة هي: الأمن والتسجيل والتحكم في المعاملات. مبدأ الأساس من التصميم الجيد هو التماسك: من الناحية المثالية، يجب أن تفعل قطعة من التعليمات البرمجية شيئا واحدا فقط. لذلك فإنه يعشق الماء لإضافة رمز الحماية إلى فئات الوصول إلى البيانات، على سبيل المثال. يحل AOP هذه مشكلة خاصة عن طريق السماح لك بإضافة السلوك في "جانب" ثم تطبيق هذا الجانب على جميع الفئات التي يجب أن تحتوي على عناصر تحكم أمنية.
AOP مختلفة عن OOP، نهج مختلفة تماما للتنمية.
في الأساس، إذا كان لديك تسجيل ومخاوف المصادقة ومخاوف التحقق من الأداء، فستكون هذه هي نفسها، تقريبا، في أجزاء مختلفة من البرنامج، في فئات مختلفة. لذلك، يمكنك كتابة طلبك أثناء تصوره، في Java، ثم عندما تحتاج إلى إضافة هذه الأنواع الأخرى من التعليمات البرمجية (مخاوف التبريد)، فأنت قد حقنها في البرنامج، بحيث يمكن تجميعها في ذلك، ولكن متى أنت تنظر إلى التعليمات البرمجية المصدرية، كما ترى فقط منطق العمل الذي تحتاجه هناك.
فيما يتعلق بموعد استخدام AOP أو OOP، أود أن أقترح عليك كتابة البرنامج، واحصل عليه على العمل، ثم عندما يكون لديك يعمل، انظر إلى إكسيد التعليمات البرمجية التي لا يلزم القيام بها بالفعل مع الوظيفة، ولكنها تخدم بعض الأغراض الأخرى. على سبيل المثال، إذا كنت بحاجة إلى التحقق من صحة معلمات الإدخال قبل استخدامها، فاستخدم جانبا لذلك. إذا كان لديك معالجة حدث مماثلة، مثل جميع الاستثناءات التي ألقيت في طبقة الوصول إلى البيانات يكتب إلى ملف السجل، فقم بإنشاء جانب لذلك.
كما يمكنك إزالة هذه الشواغل الصلاعية، ستحصل الرمز الخاص بك أصغر.
كما تحصل على المزيد من التجربة، سترى المزيد من الاستخدامات ل AOP، ولكن في البداية أقترح كتابة ذلك، ثم إعادة المرسل باستخدام AOP.
استخدم الكسوف، إذا كنت تستخدم Java، بالنسبة ل AOP، حيث سيكون البرنامج المساعد AJDT مفيدا للغاية لمعرفة المكان الذي تضيف فيه الجوانب.
البرمجة الموجهة نحو جانب الجسدة هي كلمة طنانة جذابة لإدراج الإجراءات (تسمى "المشورة") في أساليب أو وظائف في النقاط الرئيسية مثل المكالمات والعودة، من بين أمور أخرى. لدي مشكلة كبيرة مع AOP لأنها تنتهك جميع حواجز التجريد المدمجة في اللغة. لا توجد طريقة لنبلدة تقول "هذا هو ما يمكن أن يعبث الجانب به وهذا هو الجانب لا فوضى مع. "نتيجة لذلك، تخاطر بانتهاك الثبات الداخلي، وتدمير مبدأ التفكير المعياري (يمكنك فهم وحدة نمطية دون الحاجة إلى فهم أي شيء سوى واجهات الوحدات الأخرى التي تستوردها).
منذ بضع سنوات كتب ريمي ستا رسالة دكتوراه رائعة حول كيفية التحكم في اللغات الموجهة للكائن الفئة الفرعية ومنعها من انتهاك الثباتات الرئيسية. العمل المقابل ل AOP لم يكتب بعد.
بينما كما هو الحال مع أي فكرة أخرى تكسب العملة، استمتعت AOP ببعض النجاحات الرائعة (على سبيل المثال، تعديل التسجيل إلى تطبيق غير مصمم مع تسجيل الدخول في الاعتبار)، على كله سأحثك حصر استخدامك ل AOP للحالات البسيطة للغاية. وبعد أو الأفضل من ذلك، فقط قل لا البرمجة الموجهة نحو جانب الجسبي.
