PHP 包括 vs OOP答案

【问题标题】：PHP includes vs OOPPHP 包括 vs OOP
【发布时间】：2010-09-06 13:21:41
【问题描述】：

我想了解在开发 PHP 应用程序时使用 include 文件与对象（类） 的优缺点。

我知道有一个地方可以回答这个问题，我会从中受益...我有一些自己的意见，但我期待听到其他人的意见。

一个简单的例子：

我网站上的某些页面仅供登录用户访问。我有两个实现选项（还有其他选项，但我们只限于这两个）

创建一个 authenticate.php 文件并将其包含在每个页面上。它包含身份验证的逻辑。
创建一个具有认证功能的用户对象，在每个页面引用该对象进行认证。

编辑我希望以某种方式权衡一种方法的好处。我目前（和较弱的原因）如下：

包括 - 有时函数只是更容易/更短/更快地调用对象 - 功能和属性的分组有助于长期维护。

包含 - 编写更少的代码（没有构造函数，没有类语法）叫我懒惰，但这是真的。

对象 - 强制形式化和单一的功能和创建方法。

包括 - 新手更容易处理对象 - 新手较难，但专业人士不赞成。

我在项目开始时会查看这些因素，以决定是否要包含或对象。这些是我脑海中的一些优点和缺点。

【问题讨论】：

标签： php coding-style

【解决方案1】：

这些并不是真正相反的选择。无论如何，您都必须包含检查代码。我将您的问题理解为过程编程与 OO 编程。

编写几行代码或一个函数，并将其包含在您的页眉中，这就是 PHP3 或 PHP4 中的工作方式。很简单，它可以工作（这就是我们在osCommerce 中的做法，例如，一个电子商务 PHP 应用程序）。

但正如许多开发人员所证实的那样，它并不容易维护和修改。

在 PHP5 中，您将编写一个用户对象，该对象将携带自己的数据和身份验证方法。您的代码将更清晰、更易于维护，因为与用户和身份验证有关的所有内容都将集中在一个地方。

【讨论】：

【解决方案2】：

虽然该问题涉及几个非常有争议的问题（OOP、用户身份验证），但我将跳过这些问题和第二个 Konrad 关于 __autoload 的评论。任何了解 C/C++ 的人都知道包括文件在内的痛苦有多大。使用自动加载，PHP5 的一个附加功能，如果您选择使用 OOP（我几乎完全这样做），您只需要使用一些标准的文件命名约定并且（我建议）限制每个文件的单个类，PHP 将为您完成剩下的工作。清理代码，您不必再担心要记住删除不再需要的包含（包含的众多问题之一）。

【讨论】：

【解决方案3】：

我没有太多 PHP 经验，尽管我在当前的工作中使用它。一般来说，我发现大型系统受益于 OO 提供的可读性和可理解性。但一致性（不要将 OO 和非 OO 混为一谈）和您的个人偏好（尽管只针对个人项目）也很重要。

【讨论】：

【解决方案4】：

我学会了永远不要在 PHP 中使用 include，除非在我使用的核心库和应用程序中这些库（+配置）的一个中心 include 中。其他一切都由全局__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'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.
}

【讨论】：