الحقل المحمي C # إلى خاص، إضافة الممتلكات - لماذا؟

Question

في نظام فريق Visual Studio 2008، قمت فقط بتحليل رمز (من قائمة التحليل) على أحد مشاريع C # الخاصة بي. كان أحد التحذيرات المنتجة التالية:

Microsoft.Design: نظرا لأن الحقل "Connection._domain" مرئي خارج نوعه المعلن، فقم بتغيير إمكانية إمكانية الوصول إلى خاص وإضافة خاصية، مع نفس إمكانية الوصول لأن الحقل يحتوي حاليا على الوصول إليه.

إنه يشير إلى الحقل التالي:

public abstract class Connection
{
    protected string _domain;
}

أنا لا أفهم المنطق وراء الاقتراح. هذا ما أعتقد أنه يريد مني القيام به:

public abstract class Connection
{
    private string _domain;
    protected string Domain { get { return _domain; } set { _domain = value; } }
}

سؤالين:

1. هل فهمت بشكل صحيح ما يريده الاقتراح أن أفعله أو كود الحكيمة؟
2. لماذا يريدني أن أفعل هذا؟

Answer 1

نعم، أعتقد أنك مفهوم بشكل صحيح - على الرغم من أنه في الإصدارات الأحدث من C #، فهناك طريقة أكثر إيجازا لكتابةها:

public string Domain { get; set; }

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

Answer 2

نعم. هذا هو الاقتراح. لا يجب أن يكون لديك أي إمكانية الوصول أعلى من عرض خاص كحقول مثيل مباشر.

إنها واحدة من المبادئ الرئيسية ل OOD - يشار إليها أيضا باسم "مختبئ البيانات".

Answer 3

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

Answer 4

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

إذا كان هذا يؤدي فقط إلى انتشار الآجيوي البسيط والتعليقات، فأنا أعتقد أن الأضرار التي لحقت كود القراءة تفوق فائدة القدرة على تغيير الرمز في المستقبل. مع تطوير الممتلكات التي تم إنشاؤها بالمترجم في C # هذا ليس سيئا للغاية، فقط استخدم:

protected string Domain { get; set; }

Answer 5

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

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

Answer 6

في الإجابة على سؤالك ... نعم.

ومع ذلك، أود فقط استخدام بناء جملة الملكية التلقائي:

public abstract class Connection
{
    protected string Domain { get; set; }
}

Answer 7

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

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

http://social.msdn.microsoft.com/forums/en-ie/netfxbcl/thread/985f4887-92ae-4ec2-b7ae-ec8cc6eb3a42.

Answer 8

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

أعلم أنه ربما لا ينطبق عليك، ولكن قد يكون جزءا من سبب تحذير تحليل التعليمات البرمجية.