يمكن جعل الطريقة ثابتة ، ولكن هل يجب ذلك؟

Question

يحب Resharper الإشارة إلى وظائف متعددة لكل صفحة ASP.NET التي يمكن أن تكون ثابتة. هل يساعدني إذا جعلتها ثابتة؟ هل يجب أن أجعلها ثابتة ونقلهم إلى فئة فائدة؟

Answer 1

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

القاعدة CA1822 في FXCOP أو تحليل التعليمات البرمجية:

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

أنا متأكد من أن هذا لا يحدث في حالتك ، لكن "رائحة سيئة" رأيتها في بعض الكود الذي كان عليّ أن أعاني منه من خلال الحفاظ على مجموعة كبيرة من الأساليب الثابتة.

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

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

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

Answer 5

هذه قراءة مثيرة للاهتمام:

http://thecutting.com/؟p=57

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

ولكن هنا ما يقوله Resharper Documentaion:http://confluence.jetbrains.net/display/resharper/member+can+bebe+made+static

Answer 6

فقط للإضافة إلى @jason true's إجابه, ، من المهم أن ندرك أن مجرد وضع "ثابت" على الطريقة لا يضمن أن تكون الطريقة "نقية". سيكون عديمي الجنسية فيما يتعلق بالفئة التي يتم إعلانها فيها ، ولكنها قد تصل جيدًا أنا شخصياً أميل إلى تفضيل الأساليب الساكنة عندما أتمكن من أنه إذا كانت نقية ، فيمكنك الاختبار والعقل تجاههم في عزلة ، دون الحاجة إلى القلق بشأن الحالة المحيطة.

Answer 7

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

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

Answer 8

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

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

Answer 9

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

Answer 10

إذا تمت مشاركة الوظائف عبر العديد من الصفحات ، فيمكنك أيضًا وضعها في فئة صفحة أساسية ، ثم يكون لديك جميع صفحات ASP.NET التي تستخدم هذه الوظيفة ترث منها (ويمكن أن تكون الوظائف ثابتة أيضًا).

Answer 11

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

Answer 12

يساعد على التحكم في تلوث مساحة الاسم.

Answer 13

فقط بلدي tuppence: إضافة جميع الأساليب الساكنة المشتركة إلى فئة الأداة المساعدة تتيح لك إضافة

using static className; 

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

ليس لدي أي فكرة عما إذا كانت هذه ممارسة جيدة أم لا. لدي الكثير لأتعرف عليه عن C# 4/5 والكثير من التعليمات البرمجية القديمة إلى Refactor لدرجة أنني أحاول فقط ترك نصائح Roselyn يرشدني.

جوي