ما هي أفضل طريقة لتخزين PHP فئة السمات ؟

Question

مكررة من: ما هي أفضل طريقة لتخزين الدرجة المتغيرات في PHP?

منذ بعض الوقت لقد كان وجود هذه المناقشة مع زميل في العمل على كيف يجب أن متجر سمات ضمن فئة PHP.

لا تعتقد أنه ينبغي أن تستخدم.شيء من هذا القبيل:

Class test{
    public $attr1;
    public $attr2;
    .............. 
    public function __construct(){
        $this->attr1 = val;  
        $this->attr1 = val;
        ...................   
    }
}

مقابل:

Class test{
    public $data;

    public function __construct(){
        $this->data['attr1'] = val;
        $this->data['attr2'] = val;
        ..........................       
    }
}

هذا هو المهم عند الكائنات مع العديد من السمات التي يجب أن يتم تخزينها واسترجاعها في كثير من الأحيان.

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

Answer 1

النسخة 1 من "الكلاسيكية" وسيلة للقيام بهذه الأمور.وجوه الخاص بك هو بالضبط كما تقول.

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

لقد استعملت النسخة الثانية (عادة نماذج قاعدة البيانات في CodeIgniter, و لا سيما خلال التنمية في وقت مبكر) في تركيبة مع العرف PHP5 جالبة واضع طرق تسمح لك أن تفرط في الدرجة حيوي.أي

<?php
    class foo{
        private $data = array();

        function __construct()
        {
            # code...
        }

        public function __get($member) {
            if (isset($this->data[$member])) {
                return $this->data[$member];
            }
        }

        public function __set($member, $value) {
            // The ID of the dataset is read-only
            if ($member == "id") {
                return;
            }
            if (isset($this->data[$member])) {
                $this->data[$member] = $value;
            }
        }
    }

    $bar = new foo()
    $bar->propertyDoesntExist = "this is a test";
    echo $bar->propertyDoesntExist; //outputs "this is a test"
?>

Answer 2

كنت استخدم النسخة الثانية إذا وفقط إذا يأتي البيانات ككل من مصدر خارجي (مثلدينار بحريني الاستعلام).في هذه الحالة بالطبع سيكون من المفضل أن يكون عام __get()/__set() للوصول إلى $this->data.كنت قد تنظر أيضا في تنفيذ في بلدان واجهة العودة new ArrayIterator($this->data).

Answer 3

إلا إذا كانت هناك حقا حجج مقنعة لأي نسخة (depnding على السياق) أنا دائما اختار شكل يسمح ide/أدوات توفير معلومات أفضل عن أنواع, دروس, العلاقات, ...وحتى الآن هذا هو الشكل الأول.
هناك طرق أخرى للوصول إلى البيانات "مجموعة مثل".

Answer 4

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

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

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

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

Answer 5

أنا شخصيا استخدام الإصدار 1 ، لأنني أعتقد أنه هو الراجح يدعم الإكمال التلقائي في ايديس و يجعل التصحيح أسهل.

أود أيضا أن استخدام حاصل على واضعي تقريبا كل الأعضاء المتغيرات (التي تحدد خاص/محمية أكثر من مرة) ، لأن تحديد قيمة واحدة تنتج التغيرات في القيم الأخرى في كثير من الأحيان.الجانب السلبي واحد من خلق g&s هو الكم الهائل من القبيح ، الغبية البرمجية التي تتراكم مع مرور الوقت, إذا قمت بتعريف حاصل/واضعي حتى الصفات التي لا تؤدي إلى تغييرات في أماكن أخرى.أنا لا تزال تفعل ذلك من أجل واجهة متناسقة - أنا لا أعرف متى يمكنني تقديم وظائف إضافية أو بوجفيكسيس أن إدخال المزيد من التغييرات على المجموعة.

Answer 6

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

بجانب حقيقة أن IDE الخاص بك لا تعمل مع dyn.أعضاء, لا يمكنك استخدام PHPDoc لأولئك أعضاء PHPUnit لا يمكن استخدام انعكاس على تلك الصفات.هذا ببساطة سيئة أسلوب الترميز.

التحيات ، ماريو

Answer 7

السبب لاستخدام الإصدار 1 هو أن الإصدار 2 تجري داخل الكائن.وجوه الخاص بك هو بالفعل خارطة varnames إلى القيم.الخاص بك عن طريق إضافة arraymap إضافة وغني عن مستوى المراوغة.

Answer 8

أفضل طريقة للتأكد من مستوى واحد ولكن الثاني هو بالتأكيد أكثر راحة....

لي أنا استخدم أول واحد وأنا استخدم هذه الوظيفة داخل الطبقة العمل dinamically:

    public function GET__Attributes_in_Array(){
     $Prova = get_class_vars(get_class($this));
     print_r($Prova);

     return $Prova;
}

هذه الدالة تعود لك مجموعة مع كل سمات وقيمة الدرجة...