هل يستحق OOP استخدام PHP؟

Question

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

الأهم من ذلك ، هل سيكون من الجيد لف الأشياء داخل الفصل واستخدام وظائف ثابتة أم أنه من الأفضل أن يكون لديك العديد من وظائف الكذب مع بادئة Ex: WP_Function ().

Answer 1

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

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

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

function myFunc()
{
    global $class;
    $class->doMethod();
}

function myFunc2()
{
    global $class;
    $class->doMethod2();
}

هذه فكرة سيئة لأنها تخلق الكثير من الحالة العالمية.

Answer 2

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

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

Answer 3

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

نعم ، تتطلب OO المزيد من الموارد لتشغيلها. لكن فوائد استخدام OO تفوق تكلفة الأجهزة $$ (والتي من المحتمل أن تكون غير ذات أهمية) لدعم تطبيقات OO.

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

ضع في اعتبارك أنه على الرغم من أن PHP قد لا يكون أسرع منصة هناك (Java ، على سبيل المثال ، يركل بعقبها) يتم استخدام PHP لتشغيل بعض أكثر مواقع الويب التي تعمل على الإنترنت على الإنترنت: وهي Facebook.

إذا كان لديك أي شكوك أخرى حول PHP و OO ، فما عليك سوى النظر إلى Zend و Magento (استنادًا إلى Zend). Magento هو جداً منصة كثيفة الموارد ، يمكن أن يكون استخدام الذاكرة أكثر من 36 ميجابايت لكل مثيل. ومع ذلك ، فإن المنصة نفسها قادرة على التعامل مع ملايين الزيارات. وذلك لأن بيئة الخادم التي تم تكوينها بشكل صحيح مع وجبة صحية لموارد الأجهزة تجعل جميع فوائد استخدام OO تفوق تكلفة الخادم نفسه. ولكن في عالم من أجهزة الكمبيوتر المجمعة ، عدم استخدام قوة المعالجة والذاكرة (بمسؤولية) متاح لك-Imho-الجنون الإكلينيكي.

Answer 4

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

Answer 5

أنا لا أوافق بشدة على إجابة Chacha102.

الإجابة المناسبة على هذا السؤال من شأنها أن تملأ العديد من الكتب - لا تهتم بمنشور 20 خطًا هنا.

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

فيما يتعلق بملاءمة PHPS للترميز الإجرائي ، فإن جذور اللغة هي بالتأكيد في الأخير (ولكن لاحظ أن كل من Java و ASP هجين بدلاً من لغات OO الحقيقية).

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

للقول أنه يجب عليك دائمًا كتابة التعليمات البرمجية الإجرائية لأنه سيتم تشغيله بشكل أسرع من رمز OO:

1) ليس صحيحًا بالضرورة 2) يتجاهل تمامًا التكلفة النسبية لوقت المطور مقابل تكاليف الأجهزة

هل سيكون من الجيد لف الأشياء داخل الفصل واستخدام وظائف ثابتة

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

جيم

Answer 6

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

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

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

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

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

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

Answer 7

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

إليك الرمز القياسي.

class game{
  function maxp($val){
    return max(0,pow($val,0.5));        
  }
}

$game = new game;

for($i=0;$i<100000;$i++){
  $game->maxp(100);
  //game::maxp(100);
}

تراوحت نتائج OOP بين 0.13 و 0.2 ثانية ؛

تراوحت النتائج الإجرائية بين 0.08 و 0.1 ثانية.

ظلت النتائج متسقة على مدى فترة زمنية جيدة.

أشجعك على إجراء اختباراتك الخاصة.

PHP 5.4.3

Answer 8

لدى OOP مزايا أكثر من عمليات إزالة الغياق. انظر PHP OOP ، ما هي الفوائد؟. انظر أيضا ل OOP VS PP في PHP.

Answer 9

نعم مع نمو تطبيقك .. (وسوف) سيوفر لك عدة ساعات من الإحباط. وتكرار نفسك (نسخ رمز لصق في كل مكان) .. :)