التعامل مع C# الخصائص التي يجب أن لا تكون فارغة

Question

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

بالنظر إلى فئة بسيطة ، لقد رأيت عدة طرق للتعامل مع التأكد من خاصية لم null نسخة من هذه الفئة في الممتلكات

public class MyClass
{
  //Some collection of code
}

الخيار 1 - تهيئة تخزين النسخ

public class OtherClass1
    {
        private MyClass _mC = new MyClass();
        public MyClass MC
        {
            get { return _mC; }
            set { _mC = value; }
        }
    }

الخيار 2 - تهيئة مكان الإقامة في منشئ

public class OtherClass2
    {
        public MyClass MC { get; set; }     

        public OtherClass2()
        {
            MC = new MyClass(); 
        }
    }

الخيار 3 - التعامل مع التهيئة حسب الحاجة في جالبة

public class OtherClass3
    {
        private MyClass _mC;
        public MyClass MC
        {
            get
            {
                if (_mC == null)
                    _mC = new MyClass();
                return _mC; 
            }
            set { _mC = value; }
        }
    }

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

الهتافات ،

ستيف

Answer 1

والخيار الأفضل إلا إذا كنت حقا <م> يمكن تفلت من مجرد إنشاء مثيل جديد نفسك: لا توفر سوى منشئات التي تأخذ كل القيم المطلوبة، والتحقق من صحة لهم في هذه النقطة

Answer 2

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

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

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

تحديث: يبدو لي أن هناك حالة واحدة على الأقل حيث تهيئة مثيل في تعريف الفئة المناسب (لديك الخيار رقم 1). إذا كان المثال سوف يكون ساكنة ثم هذا هو المكان الوحيد المناسب <م> إلى تهيئة ما يلي:

private static readonly DateTime firstClassDate = DateTime.Parse("1/1/2009 09:00:00 AM");

وفكرت في هذا عند إنشاء خط أعلاه من التعليمات البرمجية في بعض الاختبارات وحدة كنت أكتب اليوم (و<م> للقراءة فقط يجري WRT اختياري وجهة نظري ولكن المناسب في حالتي).

Answer 3

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

ومايكروسوفت فقط صدر كود العقود ، وهي الأداة التي يتكامل مع Visual Studio ثم يسمح لك لتحديد العقود لرمز صافي الخاص بك، والحصول على وقت <م> و تجميع الوقت في التدقيق.

الفيديو على القناة 9 أن يوضح كيف يتم استخدامها.

لوالآن حان تشكل إضافة نوعية على كنها ستكون جزءا من مكتبة الفئات قاعدة في صافي 4.0

Answer 4

وعلى افتراض هناك أي آثار جانبية فيما يتعلق عندما يتم إنشاء مثيل _mC، (أي، كل شيء يجري على قدم المساواة)، أنا أفضل الخيار (3) والذي يحفظ مقدار حمل مثيل إضافية MyClass على كومة في الحالة التي يكون فيها جالبة لل MC ويطلق أبدا.

Answer 5

والخيار (3) لديه مصلحة في عدم تخصيص الكائن حتى الحاجة إليه، لأنه يمكن أن تتكيف بسهولة أن يكون كائن تأخير تحميل (حتى عند تحميل كائن من قاعدة بيانات - الحفاظ على عقد من المفاتيح الخارجية لتحميل كائن تابع الكامل عند الحاجة)

Answer 6

والخيارين 1 و 2 مختلفة نحويا ولكن ما يعادلها أساسا. الخيار 3 هو نهج الحرف الأول كسول التي تستخدم باستمرار جدا.
أعتقد أنهم جميعا استخداماتها، وذلك يعتمد على ما تحتاجه.

Answer 7

ومن الأول أن العقار لن تكون خالية أو لم فارغة على initialisation؟ وأظن أنك تعني السابق في هذه الحالة كود اضع الخاص بك يحتاج إلى منع القيم الخالية التي يجري وضعها.

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

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

Answer 8

الخيار 1 هو الفانيليا الطريقة.منذ مرة أخرى في الأيام الخوالي لم يكن السيارات-نفذت خصائص (مع { الحصول ؛ مجموعة؛} sintax) بحيث كانت طريقة تحديد السلوك الافتراضي.

عندما السيارات-تنفيذ إدخال منذ كنت لا تستخدم مباشرة في الحقل الذي يخزن القيمة الافتراضية (_mC), جيدة إلى حد ما السؤال يرتفع: "أين يمكنني تهيئة ذلك؟"

• الخيار 2 يسمى حريصة التحميل:بمجرد إنشاء الطبقة.
• الخيار 3 هو يسمى تحميل كسول :فقط في أقرب وقت الحاجة إليها.

لقد رأيت ذلك المقبولة عموما هو الخيار 2:حريصة التحميل ، ولكن أعتقد أن هذا هو فقط للحد من رمز ، وهو أمر مقبول تماما.المشكلة تأتي عندما نبدأ وجود منشئات متعددة مع العديد من التوقيعات كنت في نهاية المطاف يشير كل منها إلى الفراغ تهيئة() طريقة نوعا ما.

أنا لا سيما تفضل الخيار 3, كما هو أكثر التعريفي في مجال الملكية و هو الذاكرة الأمثل.

نلقي نظرة على EntityFramework مع نكهات مختلفة:رمز الأول أو قاعدة بيانات الأولى و ستلاحظ كيف المدمج في خصائص ويستخدم حريصة لوادر في حين الملاحة خصائص الحسنات (بشكل افتراضي ، يمكن تخصيص) كسول لوادر.

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

في رمز الأول تستطيع أن ترى في المثال التالي:

public class Blog
{ 
    public int BlogId { get; set; } 
    public string Name { get; set; } 
    public string Url { get; set; } 
    public string Tags { get; set; } 

    public virtual ICollection<Post> Posts { get; set; } 
}

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

آمل أن يكون ذلك مفيدا