المعلمة مقابل.متغيرات الأعضاء

Question

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

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

(أعترف أن العديد من ما ورد أعلاه متكرر قليلاً، لكن يبدو أن كل واحد منهم مختلف بما يكفي ليستحق مثل هذه المعاملة...)

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

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

تحرير2
تم طلب مثال على:

class foo
{
    private $_my_private_variable;

    public function __constructor__()
    {
     }

    public function useFoo( $variable )
    {
        // This is the line I am wondering about,
        // there does not seem to be a need for storing it.
        $this->_my_private_variable = $variable; 
        $this->_doSometing();
    }

    private function _doSomething()
    {

        /*
          do something with $this->_my_private_variable.
        */
        // This is the only place _my_private_variable is used.
        echo $this->_my_private_variable;
    }
}

هذه هي الطريقة التي كنت سأفعلها:

class foo
{

    public function __constructor__()
    {
     }

    public function useFoo( $variable )
    {
        $this->_doSometing( $variable );
    }

    private function _doSomething( $passed_variable )
    {
        /*
          do something with the parameter.
        */
        echo $passed_variable;
    }
}

Answer 1

بشكل عام، يجب أن يمثل أعضاء الفصل ولاية من كائن الطبقة.

إنها ليست مواقع مؤقتة لمعلمات الطريقة (هذا هو الغرض من معلمات الطريقة).

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

يجب أن يكون أعضاء الفصل أيًا مما يلي:

• تبعية الطبقة
• متغير يمثل حالة الفئة
• طريقة الطبقة

Answer 6

لست متأكدًا من وجود أفضل الممارسات المعلنة لاستخدام المتغيرات ذات النطاق العالمي مقابل التمرير دائمًا كمعلمات للطريقة.(من خلال "المتغيرات الخاصة"، أفترض أنك تقصد المتغيرات ذات النطاق العالمي.)

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

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

Answer 7

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

Answer 8

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

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

أحب أن أبقي الأمر مرنًا مع عدم الاضطرار إلى التفكير في هذا الأمر أكثر من اللازم.