هل الأعضاء/الحقول المحمية حقًا بهذا السوء؟

Question

الآن إذا قرأت اتفاقيات التسمية في MSDN لـ C# ، فستلاحظ أنه ينص على أن الخصائص تفضل دائمًا على الحقول العامة والمحمية. لقد أخبرني بعض الأشخاص أنه يجب ألا تستخدم الحقول العامة أو المحمية أبدًا. الآن سأوافق على أنه بعد أن أجد سببًا أحتاج فيه إلى الحصول على مجال عام ولكن هل هي حقول محمية حقًا بهذا السوء؟

أستطيع أن أرى ذلك إذا كنت بحاجة إلى التأكد من إجراء بعض عمليات التحقق من التحقق من الصحة عند الحصول على/تعيين القيمة ، لكن في كثير من الأحيان يبدو أن النفقات العامة الإضافية في رأيي. أعني دعنا نقول أن لدي لعبة صفية مع حقول اسم Basename و PrefixName و FaceixName. لماذا يجب أن آخذ رأس كل من إنشاء الخصائص (C#) أو أساليب الإكسسور وضرب الأداء ، فسأحدث (إذا قمت بذلك لكل حقل في أحد التطبيقات ، فأنا متأكد من أنه سيضيف أقل قليلاً خاصة بلغات معينة مثل PHP أو بعض التطبيقات ذات الأداء أمر بالغ الأهمية مثل الألعاب)؟

Answer 1

هل الأعضاء/الحقول المحمية حقًا بهذا السوء؟

لا ، إنها طريقة ، أسوأ.

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

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

ال الأفضل طريقة لمشاركة المعلومات مع الفصول المشتقة هي خاصية قراءة فقط:

protected object MyProperty { get; }

إذا كنت بالتأكيد لديك لجعله يقرأ/الكتابة ، لا. إذا كنت حقًا ، فعليًا أن تجعله يقرأ الكتابة ، أعد التفكير في التصميم. إذا كنت لا تزال بحاجة إلى أن تتم قراءة الكتابة ، اعتذر لزملائك ولا تفعل ذلك مرة أخرى :)

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

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

Answer 2

حسنًا ، الوقت المتساوي.

• بادئ ذي بدء ، لن تؤذي العقارات أبدًا الأداء (شريطة ألا تفعل الكثير). هذا ما يقوله الجميع ، وأنا أوافق.

• نقطة أخرى هي أن الخصائص جيدة من حيث يمكنك وضع نقاط التوقف فيها لالتقاط أحداث الحصول على/إعداد ومعرفة من أين أتت.

بقية الحجج تزعجني بهذه الطريقة:

• أنها تبدو مثل "حجة من قبل Prestige". إذا قال MSDN ذلك ، أو بعض المطورين أو المؤلف الشهير الذي يحبها الجميع ، فهذا يجب كن كذلك.

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

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

Answer 3

فيما يتعلق بالحقول مقابل الخصائص ، يمكنني التفكير في سببين لفضح العقارات في الواجهة العامة (المحمية هي أيضًا عامة بمعنى أن شخصًا آخر غير فصلك فقط يمكنه رؤيته).

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

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

فيما يتعلق بالنفقات العامة:

• إذا كان Getter/Setter هو قطعة الخط المعتاد من الكود الذي يقرأ/يعين ببساطة قيمة الحقل ، فيجب أن يكون JIT قادرًا على تحديد المكالمة ، لذلك لا يوجد أي زيادة في الأداء.

• يتم تقليل النفقات العامة النحوية إلى حد كبير عند استخدام الخصائص التي تم تنفيذها تلقائيًا (C# 3.0 وأحدث) ، لذلك لا أعتقد أن هذه مشكلة:

  protected int SomeProperty { get; set; }
  

  في الواقع ، هذا يتيح لك صنع على سبيل المثال set محمية و get الجمهور بسهولة شديدة ، لذلك يمكن أن يكون هذا أكثر أناقة من استخدام الحقول.

Answer 4

الحقول العامة و/أو المحمية سيئة لأنه يمكن معالجتها من خارج فئة الإعلان دون التحقق من الصحة ؛ وبالتالي يمكن قولهم لكسر مبدأ التغليف للبرمجة الموجهة للكائنات.

عندما تفقد التغليف ، تفقد عقد فئة الإعلان ؛ لا يمكنك ضمان أن الفصل يتصرف على النحو المقصود أو المتوقع.

يتيح لك استخدام خاصية أو طريقة للوصول إلى الحقل الحفاظ على التغليف ، والوفاء بعقد فئة التصريح.

Answer 5

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

لكن عندما أكون في العمل ، هذه قصة مختلفة.

Answer 6

يعتمد الأمر فعليًا على ما إذا كان فصلك فئة بيانات أو فئة سلوك.

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

إذا كان الفصل عبارة عن فئة سلوك ، فيجب ألا يعرض أي بيانات.