PHP включает vs OOP

Я хотел бы иметь ссылку на плюсы и минусы использования include файлов против объектов (классов) при разработке приложений PHP.

Я знаю, что выиграю от одного места, чтобы пойти на этот ответ... У меня есть несколько собственных мнений, но я с нетерпением жду других.

Простой пример:

Некоторые страницы на моем сайте доступны только для зарегистрированных пользователей. У меня есть два варианта реализации (есть и другие, но ограничьте их этими двумя)

  • Создайте файл authenticate.php и включите его на каждую страницу. Он поддерживает логику аутентификации.

  • Создайте объект пользователя, который имеет функцию аутентификации, ссылается на объект для аутентификации на каждой странице.

Edit Я бы хотел, чтобы кто-то оценил преимущества одного над другим. Мои текущие (и слабые причины) следуют:

Включает - Иногда функция просто проще/короче/быстрее звонить Объекты. Группирование функциональности и свойств приводит к долгосрочному обслуживанию.

Включает. Меньший код для записи (без конструктора, без синтаксиса класса) называет меня ленивым, но это правда.

Объекты. Форсирует формальность и единый подход к функциям и созданию.

Включает - проще для новичка иметь дело с Объекты - труднее для новичков, но нахмурились профессионалами.

Я рассматриваю эти факторы в начале проекта, чтобы решить, хочу ли я делать включения или объекты. Это несколько плюсов и минусов от моей головы.

ОТВЕТЫ

Ответ 1

Это не совсем противоположный выбор. В любом случае вам придется включать код проверки. Я прочитал ваш вопрос как процедурное программирование и программирование OO.

Написание нескольких строк кода или функции, включая включение в заголовок страницы, было сделано в PHP3 или PHP4. Это просто, он работает (что мы сделали это в osCommerce, например, приложение PHP для электронной коммерции).

Но это нелегко поддерживать и модифицировать, как это может подтвердить многие разработчики.

В PHP5 вы должны написать объект пользователя, который будет иметь свои собственные данные и методы аутентификации. Ваш код будет более понятным и простым в обслуживании, поскольку все, что связано с пользователями и аутентификация, будет сосредоточено в одном месте.

Ответ 2

В то время как вопрос затрагивает пару очень дискуссионных проблем (OOP, User authentication), я пропущу те и второй комментарий Konrad о __autoload. Любой, кто знает C/С++, знает, какая боль, включая файлы, может быть. С автозагрузкой, добавлением PHP5, если вы решите использовать ООП (что я делаю почти исключительно), вам нужно использовать только стандартное соглашение об именах файлов и (я бы рекомендовал) ограничение одного класса на файл, а PHP сделает все остальное за вас. Очищает код, и вам больше не нужно беспокоиться о том, чтобы помнить об удалении включений, которые больше не нужны (одна из многих проблем с включением).

Ответ 3

У меня мало опыта работы с PHP, хотя я использую его в своей текущей работе. В общем, я считаю, что более крупные системы выигрывают от удобочитаемости и понятности, которые предоставляет OO. Но важны такие вещи, как согласованность (не смешивайте OO и non-OO), а также ваши личные предпочтения (хотя и действительно в личных проектах).

Ответ 4

Я научился никогда не использовать include в PHP, кроме встроенных основных библиотек, которые я использую, и одной центральной include этих библиотек (+ config) в приложении. Все остальное обрабатывается глобальным обработчиком __autoload, который может быть настроен для распознавания различных классов. Это можно сделать легко, используя соответствующие соглашения об именах для классов.

Это не только гибкий, но и достаточно эффективный и сохраняет архитектуру чистой.

Ответ 5

Можете ли вы быть более конкретным? Для примера, который вы даете, вам нужно использовать include в обоих направлениях. В случае 1 вы включаете только файл, в случае 2 вам нужно включить файл класса (например, user.class.php), чтобы создать экземпляр класса User.

Это зависит от того, как построена остальная часть приложения, это OO? Используйте OO.

Ответ 6

Если вы делаете это в классах или в более процедурном стиле, вам просто нужно проверить, чтобы:

  • Существует сеанс;
  • Что сеанс действителен; и,
  • То, что пользователь, владеющий сеансом, имеет соответствующие привилегии.

Вы можете инкапсулировать все три шага в одну функцию (или статический метод в классе Session может работать). Попробуйте следующее:

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 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.
}