هل يجب علي استخدام الرؤية الداخلية أو العامة بشكل افتراضي؟

StackOverflow https://stackoverflow.com/questions/106941

  •  01-07-2019
  •  | 
  •  

سؤال

أنا مطور جديد جدًا لـ C# و.Net.لقد قمت مؤخرًا بإنشاء أداة إضافية لـ MMC باستخدام C# وكنت سعيدًا بمدى سهولة القيام بذلك، خاصة بعد سماع الكثير من قصص الرعب من قبل بعض المطورين الآخرين في مؤسستي حول مدى صعوبة القيام بذلك في C++.

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

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

المحلول

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

ولتحقيق هذه الغاية، أعطني فقط الوظيفة التي يحتاج الفصل إلى كشفها للعمل.

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

نصائح أخرى

ما فعلته هو بالضبط ما يجب عليك فعله؛امنح فصولك الحد الأدنى من الرؤية الممكنة.تبا، إذا كنت تريد حقا أن تذهب إلى خنزير كامل، يمكنك أن تفعل ذلك كل شئ internal (على الأكثر) واستخدم InternalsVisibleTo يصف, ، بحيث يمكنك فصل وظائفك مع عدم تعريضها للعالم الخارجي المجهول.

السبب الوحيد لنشر الأشياء للعامة هو أنك تقوم بتغليف مشروعك في العديد من ملفات DLL و/أو EXEs و(لأي سبب كان) لا تهتم باستخدامها InternalsVisibleTo, أو أنك تقوم بإنشاء مكتبة لتستخدمها جهات خارجية.ولكن حتى في المكتبة المخصصة للاستخدام من قبل أطراف ثالثة، يجب أن تحاول تقليل "مساحة السطح" حيثما أمكن ذلك؛كلما زاد عدد الفصول المتاحة لديك، زادت إرباك مكتبتك.

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

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

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

أفضّل تجنب وضع علامات على الفصول كـ public إلا إذا كنت أريد صراحةً أن يستهلكها عميلي، وأنا على استعداد لدعمها.

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

يجب أن تكون معظم الفصول الدراسية internal, ، ولكن ينبغي أن يكون معظم الأعضاء غير الخاصين public.

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

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

يجب أن تميل نحو كشف أقل قدر ممكن للفئات الأخرى، والتفكير مليًا فيما تقوم بكشفه ولماذا.

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

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

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

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

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

لقد واجهت مشكلة مؤخرًا حيث كان المصمم يستمر في إزالة سطر this.myControl = new MyControl() من الأسلوبInitializeComponent() لأنه تم وضع علامة على UserControl MyControl على أنه داخلي مع المُنشئ الخاص به.

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

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

لا تختر الاختيار "الافتراضي" الذي يناسب احتياجات الرؤية لتلك الفئة المعينة.عند اختيار فئة جديدة في Visual Studio، يتم إنشاء القالب على النحو التالي:

class Class1
{
}

وهو خاص (نظرًا لعدم تحديد نطاق).الأمر متروك لك لتحديد نطاق الفصل (أو تركه خاصًا).يجب أن يكون هناك سبب لفضح الفصل.

أحب أن أكشف الأشياء بأقل قدر ممكن.خاص، محمي، داخلي، عام:منح الفئات والمتغيرات والخصائص والوظائف أقل قدر من الرؤية التي تحتاجها حتى يستمر كل شيء في العمل.

سأقوم برفع رؤية شيء ما إلى تلك السلسلة تجاه الجمهور فقط عندما يكون هناك سبب وجيه لذلك.

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

اليوم، اضطررت إلى استخدام الانعكاس للوصول إلى الأجزاء الداخلية لـ System.Data.DataTable (لا بد لي من إنشاء جدول بيانات بسرعة البرق، دون كل عمليات التحقق منه)، واضطررت إلى استخدام الانعكاس، حيث لا يوجد نوع واحد كان متاحا لي.تم وضع علامة عليهم جميعًا على أنهم داخليون.

افتراضيًا، يتم إنشاء الفئة على أنها داخلية في c#:الوسائل الداخلية:يقتصر الوصول على التجميع الحالي.

يرىhttp://msdn.microsoft.com/en-us/library/0b0thckt.aspx

مقالة جيدة نطاق الإعدادات الافتراضية داخلي:http://www.c-sharpcorner.com/UploadFile/84c85b/default-scope-of-a-C-Sharp-class/

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