سؤال

وإذا كان من الأفضل لتهيئة المتغيرات عضو فئة على إعلان

private List<Thing> _things = new List<Thing>();
private int _arb = 99;

وأو في المنشئ الافتراضي؟

private List<Thing> _things;
private int _arb;

public TheClass()
{
  _things = new List<Thing>();
  _arb = 99;
}

هل مجرد مسألة أسلوب أم أن هناك أداء المقايضات، بطريقة أو أخرى؟

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

المحلول

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

ويمكن استخدام نهج منشئ مع خصائص نفذت السيارات (المهيآت المجال لا يمكن) - أي بمعنى

[DefaultValue("")]
public string Foo {get;set;}
public Bar() { // ctor
  Foo = "";
}

وبخلاف ذلك، فإنني أميل إلى تفضيل بناء الجملة مهيئ الميدان؛ أجد أنه يبقي الأمور المترجمة - أي بمعنى

private readonly List<SomeClass> items = new List<SomeClass>();
public List<SomeClass> Items {get {return items;}}

وأنا لم يكن لديك للذهاب الصيد صعودا وهبوطا لمعرفة أين يتم تعيينه ...

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

public Bar() : this("") {}
public Bar(string foo) {Foo = foo;}

وتحرير: كتعليق الجانب، لاحظ أن في أعلاه، إذا كان هناك مجالات أخرى (لا يظهر) مع المهيآت الحقل، ثم أنها ليست سوى تهيئة مباشرة في المنشئات التي تدعو base(...) - أي المنشئ public Bar(string foo). منشئ الآخر لا <م> لا تشغيل المهيآت المجال، لأنه يعلم تتم من قبل المنشئ this(...).

نصائح أخرى

والواقع، المهيآت الحقل كما كنت التظاهر هو اختزال مريحة. المترجم في الواقع نسخ رمز التهيئة في بداية كل منشئ المثال التي تقوم بتعريف لنوع.

وهذا له أثران: الأول، هو تكرار أي رمز التهيئة الميدانية في كل منشئ، والثانية، أي الرمز الذي تدرج في منشئات لتهيئة الحقول لقيم معينة في واقع إعادة تعيين-حقول

وهكذا الأداء الحكمة، وفيما يتعلق بحجم التعليمات البرمجية المترجمة، كنت أفضل حالا تتحرك المهيآت الحقل إلى الصانعين.

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

وقيود رئيسي واحد مع المهيآت المجال هو أن ليس هناك طريقة للالتفاف عليها في كتلة المحاولة، أخيرا. إذا تم طرح استثناء في مهيئ الحقل، سيتم التخلي عن أي الموارد التي تم تخصيصها في المهيآت السابقة؛ ليس هناك طريقة لمنع ذلك. أخطاء أخرى في البناء يمكن التعامل معها، إذا برعونة، من خلال وجود منشئ قاعدة محمية يقبل على IDisposable بالرجوع، ولافتا أنه في حد ذاته كأول جدا عملها. يمكن للمرء ثم تجنب استدعاء منشئ إلا من خلال وسائل المصنع الذي في حالة استثناء سيدعو تخلص على كائن تم إنشاؤه جزئيا. وهذه الحماية تسمح لتنظيف IDisposables إنشاؤها في المهيآت-فئة مشتقة إذا فشل منشئ من الدرجة الرئيسية بعد "بتهريب" في اشارة الى وجوه جديدة. للأسف، لا توجد طريقة لتوفير هذه الحماية إذا فشل مهيئ المجال.

استخدم إما المهيآت المجال أو إنشاء وظيفة التهيئة (). المشكلة مع وضع هذه الأمور في المنشئ الخاص بك هو أنه إذا كنت في حاجة من أي وقت مضى لإضافة منشئ 2ND، ينتهي بك الأمر مع رمز نسخ / لصق (أو تتركها وينتهي مع المتغيرات غير مهيأ).

وأنا إما تهيئة حيث المعلنة. أو أن يكون المنشئ (ق) استدعاء دالة التهيئة ().

لمتغيرات سبيل المثال، هو إلى حد كبير مسألة أسلوب (انا افضل استخدام منشئ). للمتغيرات ثابتة، هناك ل تهيئة مضمنة (ليس من الممكن دائما، بالطبع).

وانها حقا متروك لكم.
أنا في كثير من الأحيان تهيئة لهم مضمنة، والسبب أنني لا أحب أن منشئ عندما كنت لا تحتاج حقا واحدة (أنا أحب الفصول الصغيرة!).

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

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

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