PHP包括vs OOP

时间:2008-08-22 14:41:21

标签: php coding-style

我想在开发PHP应用程序时参考使用include 文件vs对象(类)的优缺点。

我知道我可以从一个地方获得这个答案中受益...我对自己有一些看法,但我期待听到其他人的意见。

一个简单示例:

我的网站上的某些页面只能由登录用户访问。我有两个实现选项(还有其他选项,但我们将其限制为这两个选项)

  1. 创建authenticate.php文件并将其包含在每个页面上。它具有身份验证的逻辑。

  2. 创建一个具有身份验证功能的用户对象,在每个页面上引用该对象进行身份验证。

  3. 修改 我希望看到某种方式权衡一方的好处。 我目前(和弱的理由)遵循:

    包含 - 有时功能更容易/更短/更快 对象 - 功能和属性的分组导致长期维护。

    包含 - 更少编写的代码(没有构造函数,没有类语法)称我为懒惰但这是真的。

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

    包含 - 新手更容易处理 对象 - 对于新手来说更难,但是专业人士不赞成。

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

6 个答案:

答案 0 :(得分:13)

这些并非真正相反的选择。无论如何,您必须包含检查代码。我把你的问题看作是程序编程与OO编程。

编写几行代码或函数,并将其包含在页眉中是PHP3或PHP4中完成的工作。它很简单,它可以工作(这就是我们在osCommerce中所做的事情,例如,电子商务PHP应用程序)。

但是,维护和修改并不容易,因为许多开发人员都可以确认。

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

答案 1 :(得分:5)

虽然这个问题触及了几个非常有争议的问题(OOP,用户身份验证),但我会跳过这些以及第二个Konrad对__autoload的评论。任何了解C / C ++的人都知道包括文件在内的多少痛苦。使用自动加载,PHP5添加,如果您选择使用OOP(我几乎专门做),您只需要使用一些标准文件命名约定(我建议)限制每个文件的单个类,PHP将为您完成剩下的工作。清理代码,您不再需要担心记住删除不再需要的包含(包括许多问题之一)。

答案 2 :(得分:1)

虽然我在目前的工作中使用它,但我没有太多的PHP经验。总的来说,我发现大型系统受益于OO提供的可读性和可理解性。但是一致性(不要混合OO和非OO)和你的个人偏好(尽管只是在个人项目上)也很重要。

答案 3 :(得分:1)

我学会了永远不要在PHP中使用include,除了我使用的核心库和应用程序中这些库(+ config)的一个中心include。其他所有内容都由全局__autoload处理程序处理,该处理程序可以配置为识别所需的不同类。这可以使用适当的类命名约定轻松完成。

这不仅灵活,而且非常有效,并保持架构清洁。

答案 4 :(得分:0)

你能更具体一点吗?对于您给出的示例,您需要以两种方式使用include。 在案例1中,您只包含一个文件,在案例2中,您需要包含类文件(例如user.class.php)以允许实例化User类。

这取决于应用程序的其余部分是如何构建的,是OO吗?使用OO。

答案 5 :(得分:0)

无论是在课堂上还是以程序化的方式进行,您只需要检查以确保:

  1. 有一个会话;
  2. 会话有效;和,
  3. 拥有会话的用户具有适当的权限。
  4. 您可以将所有三个步骤封装到一个函数中(或者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.
    }