PHP يتضمن مقابل OOP

Question

أرغب في الحصول على مرجع لإيجابيات وسلبيات استخدام include الملفات مقابل الكائنات (الفئات) عند تطوير تطبيقات PHP.

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

مثال بسيط:

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

1. قم بإنشاء ملف Authenticate.php وقم بتضمينه في كل صفحة.إنه يحمل منطق المصادقة.

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

يحررأود أن أرى طريقة ما تزن فوائد أحدهما على الآخر.فيما يلي الأسباب الحالية (والأسباب الضعيفة):

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

يشمل - كود أقل للكتابة (لا يوجد مُنشئ، ولا يوجد بناء جملة للفصل) يدعوني بالكسل ولكن هذا صحيح.

أشياء - فرض الشكليات ونهج واحد للوظائف والإبداع.

يشمل - أسهل على المبتدئين للتعامل مع الأشياء - صعوبة بالنسبة للمبتدئين ، ولكن من قبل المهنيين.

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

Answer 1

هذه ليست خيارات معاكسة حقًا.سيتعين عليك تضمين رمز التحقق على أي حال.قرأت سؤالك كبرمجة إجرائية مقابل برمجة إجرائية.برمجة اوو.

إن كتابة بضعة أسطر من التعليمات البرمجية، أو وظيفة، وإدراجها في رأس صفحتك هو الطريقة التي تتم بها الأمور في PHP3 أو PHP4.إنه أمر بسيط، إنه يعمل (وهذه هي الطريقة التي فعلناها بها com.osCommerce, ، على سبيل المثال، تطبيق PHP للتجارة الإلكترونية).

لكن ليس من السهل صيانته وتعديله، كما يؤكد العديد من المطورين.

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

Answer 2

بينما يتطرق السؤال إلى بعض المشكلات المثيرة للجدل (OOP، مصادقة المستخدم) سأتخطى تلك المشكلات وتعليق كونراد الثاني حول __autoload.أي شخص يعرف C/C++ يعرف مقدار الألم الذي يمكن أن يحدثه بما في ذلك الملفات.مع التحميل التلقائي، إضافة PHP5، إذا اخترت استخدام OOP (وهو ما أفعله بشكل حصري تقريبًا)، فأنت تحتاج فقط إلى استخدام بعض اصطلاحات تسمية الملفات القياسية و(أوصي) بتقييد فئة واحدة لكل ملف وستقوم PHP بالباقي نيابةً عنك.ينظف الكود ولا داعي للقلق بعد الآن بشأن تذكر إزالة التضمينات التي لم تعد ضرورية (واحدة من المشاكل العديدة المتعلقة بالتضمينات).

Answer 3

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

Answer 4

لقد تعلمت عدم الاستخدام أبدًا include في PHP باستثناء المكتبات الأساسية التي أستخدمها وواحدة مركزية include من هذه المكتبات (+ التكوين) في التطبيق.يتم التعامل مع كل شيء آخر من خلال عالمي __autoload معالج يمكن تهيئته للتعرف على الفئات المختلفة المطلوبة.يمكن القيام بذلك بسهولة باستخدام اصطلاحات التسمية المناسبة للفئات.

هذا ليس مرنًا فحسب، بل إنه فعال أيضًا ويحافظ على نظافة البنية.

Answer 5

هل يمكن أن يكون قليلا أكثر تحديدا؟على سبيل المثال الذي قدمته تحتاج إلى استخدام التضمين في كلا الاتجاهين.في الحالة 1، تقوم بتضمين ملف فقط، وفي الحالة 2، تحتاج إلى تضمين ملف الفئة (على سبيل المثال user.class.php) للسماح بإنشاء مثيل لفئة المستخدم.

يعتمد الأمر على كيفية إنشاء بقية التطبيق، هل هو OO؟استخدم اوو.

Answer 6

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

1. هناك جلسة؛
2. أن تكون الجلسة صالحة؛و،
3. أن المستخدم الذي يمتلك الجلسة لديه الامتيازات المناسبة.

يمكنك تغليف الخطوات الثلاث في وظيفة واحدة (أو قد تعمل طريقة ثابتة في فئة الجلسة).جرب هذا:

class Session
{
  const GUEST = 0;
  const SUBSCRIBER = 1;
  const ADMINISTRATOR = 2;

  public static function Type()
  {
    session_start();

    // Depending on how you use sessions on
    // your site, you might just check for the
    // existence of PHPSESSID. If you track
    // every visitor with sessions, however, you
    // might want to assign some separate unique
    // number (that you can track in a DB) to
    // authenticated sessions
    if(!$_SESSION['uniqid'])
    {
      return Session::GUEST;
    }
    else
    {
      // For the best security, don't store the
      // user's access permissions in the $_SESSION,
      // but rather check against the DB. This will
      // ensure that recently deleted or downgraded
      // administrators will not be able to make use
      // of a previous session.

      return THE_ACCESS_LEVEL_ACCORDING_TO_THE_DB
    }
  } 
}


// In your files that need to check for authentication (you
// could also do this in a controller if you're going MVC

if(!(Session::Type() == Session::ADMINISTRATOR))
{
  // Redirect them to wherever you want them to go instead,
  // like a log in page or something like that.
}