التغليف في عصر الأطر

Question

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

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

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

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

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

Answer 1

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

يأخذ كائن العلائقية الأطر; ؛ يسمح لك معظمهم بتحديد كيفية ذهابهم إلى ترطيب الكيانات؛ nhibernate على سبيل المثال يسمح لك بذلك access="property" أو access="field.camelcase" ومتشابه هذا يسمح لك بتغليف خصائصك.

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

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

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

ثانيا، حول فصول ملموسة كخصائص: يجب أن تكون حذرا بشأن أنواع الأنواع؛) تكشف كخصائص. قل لديك قائمة في مثالتك؛ ثم لا تعرض ilist كمية؛ من المحتمل أن تسرب هذا ولا يمكنك ضمان عدم إضافة المستهلكين للواجهة أشياء أو إزالة الأشياء التي تعتمد عليها؛ بدلا من ذلك، تعرض شيئا مثل ienumerable وإرجاع نسخة من القائمة، أو حتى أفضل، افعلها كأسلوب: Public IEnumerable MyCollection {احصل على {إرجاع _List.enum ()؛ }} ويمكنك أن تكون مؤكدا بنسبة 100٪ للحصول على الأداء والجليد. لا يمكن ل Noone إضافة أو إزالتها إلى ذلك iEnaryerable ولا تزال لا تضطر إلى تنفيذ نسخة مميزة للمصفاة. طريقة المساعد المقابلة:

static class Ext {
    public static IEnumerable<T> Enum<T>(this IEnumerable<T> inner) {
        foreach (var item in inner) yield return item;
    }
}

لذلك في حين لا يمكنك الحصول على تغليف بنسبة 100٪ في القول إنشاء المشغلين / الطريقة التي يمكن أن تقترب من واجهاتك العامة.

يمكنك أيضا استخدام الميزات الجديدة من .NET 4.0 المدمج على المواصفات # للتحقق من العقود التي تحدثت عنها أعلاه.

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

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

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

Answer 2

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

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

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

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

Answer 3

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