التغليف ضمن تعريفات الفئة

Question

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

Answer 1

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

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

يحرر: يقرأ الخصائص التلقائية مقابل الخصائص الصريحة بقلم إريك ليبرت حيث يتعمق في هذه القضية ويشرح الأمور بوضوح شديد.يتعلق الأمر بـ C# على وجه التحديد ولكن نظرية OOP عالمية ومتينة.

هنا مقتطف:

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

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

Answer 2

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

Answer 3

تم تصميم الملحقات بحيث يمكنك إضافة منطق خاص بالخاصية.مثل

int Degrees
{
    set
    {
        _degrees = value % 360;
    }
}

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

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

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

يحرر

انظر هذا السؤال أيضًا:تصميم اوو:هل تستخدم الممتلكات العامة أو الحقول الخاصة داخليًا؟

Answer 4

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

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

وعلى أي حال، وهذا بلدي [الزنجار تغطية] اثنين سنتا.

Answer 5

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

من:

    private int[] Property { get; set; }

إلى

    private int[] _property;
    private int[] Property
    {
        get { return _property; }
        set { _property = value; }
    }

إلى

    private int[] _property;
    private int[] Property
    {
        get
        {
            if (_property == null)
            {
                _property = new int[8];
            }
            return _property;
        }
        set { _property = value; }
    }

إلى

    private int[] Property
    {
        get
        {
            if (ViewState["PropertyKey"] == null)
            {
                ViewState["PropertyKey"] = new int[8];
            }
            return (int[]) ViewState["PropertyKey"];
        }
        set { ViewState["PropertyKey"] = value; }
    }

وبطبيعة الحال، وأنا استخدم ReSharper، لذلك هذا يستغرق وقتا أقل للقيام من نشر عنه.