سؤال

ما رأيك في استخدام طرق ثابتة خاصة?

أنا شخصياً أفضل استخدام أ ثابتة طريقة خاصة ل غير ساكنة طالما أنه لا يتطلب الوصول إلى أي حقول المثيل.

لكنني سمعت أن هذه الممارسة تنتهك مبادئ OOP.

يحرر:أنا أتساءل من منظور الأسلوب وليس الأداء.

هل كانت مفيدة؟

المحلول

أ private static لا تنتهك الطريقة في حد ذاتها OOP في حد ذاتها، ولكن عندما يكون لديك الكثير من هذه الأساليب في فئة لا تحتاج (ولا يمكنها*) الوصول إلى حقول المثيلات، فأنت لا تبرمج بطريقة OO، لأن "الكائن" يعني ضمنيًا الحالة + العمليات على تلك الحالة المحددة معًا.لماذا تضع هذه الأساليب على هذا الفصل إذا لم تكن بحاجة إلى أي حالة؟

(*) = من حيث المبدأ، نظرًا لإمكانية رؤية مستوى الفصل في Java، فهي طريقة ثابتة في الفصل لديه الوصول إلى حقول مثيل كائن من تلك الفئة، على سبيل المثال:

class Test
{
  int field = 123;

  private static void accessInstance(Test test)
  {
    System.out.println(test.field);
  }
}

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

نصائح أخرى

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

(ملاحظة، الأساليب الثابتة الخاصة نهائية ضمنيًا)

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

تحقق من الورقة بأكملها: http://renaud.waldura.com/doc/Java/final-keyword.shtml

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

لا أرى بالضرورة أي مشكلة حقيقية فيما تفعله، ولكن سؤالي الأول هو إذا كانت الطريقة لا تتطلب الوصول إلى أي حقول مثيل، فماذا تفعل في هذا الفصل في المقام الأول؟

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

أنا لا أميل إلى استخدام الأساليب الثابتة الخاصة.أنا أستخدم الأساليب الثابتة العامة وأقوم بتجميعها في فئات Util لتعزيز إعادة الاستخدام.

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

العيب الرئيسي لاستخدام الأساليب الثابتة هو في رأيي حقيقة أن المرء يستبعد إمكانية التجاوز.نظرًا لأن الفئات في Java ليست مثل الفئات الموجودة في Smalltalk، على سبيل المثال، فلا يمكنك تجاوز الأساليب الثابتة.

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

أميل إلى استخدام الأساليب الثابتة فقط في حالة الفئات المساعدة (مثل java.lang.Math) أو الأنماط مثل نمط Singleton.كل هذه تتطلب رؤية أعلى من القطاع الخاص، لأنها تمثل الخدمات التي تقدمها فئتها للآخرين.

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top