فصول جزئية في C#

https://stackoverflow.com/questions/160514

03-07-2019
|

سؤال

هل هناك استخدامات جيدة للفئات الجزئية خارج سيناريوهات رمز WebForms/WinForms؟ أم أن هذه الميزة أساسا لدعم ذلك؟

المحلول

إنه جزئيًا لدعم السيناريوهات (WebForms و WinForms و LINQ-to-SQL و ETC) التي تم خلطها مع رمز المبرمج.

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

نصائح أخرى

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

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

يستخدم المشروع الذي أعمل عليه حاليًا على جيل التعليمات البرمجية لجميع كيانات DAL و BLL و Business. ومع ذلك ، فإن المولد يحصل فقط على 75 ٪ من المعلومات. يجب ترميز الجزء المتبقي باليد (منطق الأعمال المخصص على سبيل المثال). أستطيع أن أفترض أن كل فئة من فئة BLL لديها طريقة مختارة ، بحيث يسهل إنشاءها. ومع ذلك ، يحتاج العميل BLL أيضًا إلى الحصول على طريقة SelecallByLocation. لا يمكنني وضع هذا في مولد بلدي لأنه ليس عاما لجميع فصول BLL. لذلك أقوم بإنشاء جميع فصولي كطبقات جزئية ، ثم في ملف منفصل أقوم بتحديد أساليب مخصصة. الآن على الطريق عندما يتغير هيكيتي ، أو أحتاج إلى تجديد BLL الخاص بي لسبب ما ، لن يتم القضاء على الرمز المخصص الخاص بي.

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

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

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

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

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

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

// Main Part
public partial class Class1
{
    private partial void LogSomethingDebugOnly();

    public void SomeMethod()
    {
        LogSomethingDebugOnly();
        // do the real work
    }
}

// Debug Part - probably in a different file
public partial class Class1
{

    #if DEBUG

    private partial void LogSomethingDebugOnly()
    {
        // Do the logging or diagnostic work
    }

    #endif
}

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

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

كما ذكرنا سابقًا ، أعتقد أيضًا أن هذه رائحة رمز.

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

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

ربما فات الأوان ولكن واسمحوا لي أن أضيف 2 سنتا أيضا:

*. عند العمل في المشاريع الكبيرة ، يتيح نشر الفصل على ملفات منفصلة المبرمجين المتعددين العمل عليها في وقت واحد.

*. يمكنك بسهولة كتابة التعليمات البرمجية الخاصة بك (للوظائف الموسعة) لفئة VS.NET التي تم إنشاؤها. سيسمح لك ذلك بكتابة رمز احتياجك دون العبث باستخدام رمز النظام الذي تم إنشاؤه

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

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

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

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

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

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

بشكل عام ، أنا أعتبرها رائحة رمز.

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

أو يعني أنه لا يوجد تسلسل هرمي للميراث حيث يجب أن يكون هناك واحد.

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

لقد تأخرت في اللعبة ... لكن فقط 2 سنت ...

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

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

تصحيح ، كما أشار مات ، يجب أن يكون كلا جانبي الجزئي في نفس التجمع. خطأي.

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

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

لقد وجدت فقط استخدامًا للفصول الجزئية. لدي فئة [DataContract] التي أستخدمها لتمرير البيانات إلى العميل. أردت أن يكون العميل قادرًا على عرض الفصل بطريقة محددة (إخراج النص). لذلك قمت بإنشاء فئة جزئية وتجاوز طريقة tostring.

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

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

في أي مكان تستخدمه #region من المحتمل أن تكون الأقسام قبل أن تكون أكثر منطقية كملفات منفصلة في فئات جزئية.

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

تحرير: تستخدم أدوات DSL لـ Visual Studio فئات جزئية.

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

من الجيد أن يكون لديك هذا الاختيار الذي يمكنك الجمع بينه - ولكن لا يجبر على استخدامه مع الميراث

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

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow