OOP的PHP长啥样

在PHP的论坛中总是听到有人对PHP的OOP支持说三道四的，说这有缺陷，那里不足，但是都拿不出实际的例子。原来说过要和大家说说这事，但是一直很 忙，现在算是抽了些时间了，所以把我刚刚做过的一个项目的框架拿出来和大家探讨一下。这个项目99%的代码是用oop方式编写的，感觉PHP对于OOP支 持非常好，不是一般的好，是非常的好。有由于项目本身是一个商业项目所以源代码不好公布出来，但是基本框架还是可以说一说的，而且经过简化的例子更容易理 解一些。如果你对PHP中的OOP还不太了解，还是就此打住吧，先去看看手册，或者基础读物再来看也不迟，反正这个是贴子没有长腿也跑不了。

长话短说，立刻开始吧。我这里会用到一个简单的例子，只有一个半的功能。一个是向浏览器发送一句"Hello, I can say OOP in PHP world!"，另外半个功能是从数据库中进行一个查询然后输出到浏览器，说它是半个功能是因为只是作为一个例子讲讲没有实际的数据库操作。

首先从我的第一个文件index.php 开始介绍吧。我的index.php文件是这样的：

CODE:

<?php
include_once ('config.php');
include_once ('class.Application.php');
$app = & new Application();
$app->;run();
?&gt;;

这个就是全部了，虽然只有4行，但是如果用OOP的方式写这个应该就够了吧。
有一点经验的哥们会发现这里只用到了一个Application 对象，那么一定很想知道这个对象究竟长什么样呢？我们继续看看class.Application.php 这个文件的内部。从以上的代码中我们知道她应该至少包含两个方法
Application()
和
run()
所以大体上应该长成这样

CODE:

<?php

class Application
{
function Application()
{

}

function run()
{

}
}

?>;

现在就算知道Application 是什么样，它好像也没有办法完成我们预先设定的功能呀？ 所以还要介绍一下如何运行这个程序，在我的结构中所有的页面都是通过index.php和一个action参数进行访问的例如第一个功能应该这样访问 index.php?action=HelloPage，而第二个功能则是通过index.php?action=DatabasePage进行访问。这 样的结构大家也许并不陌生吧。所以index.php 页面应当知道传进来的 action 参数是什么，也就是说Application对象应当知道 这个action 参数是什么。所以我们需要给Application增加一个方法 getAction()来获得action参数。既然知道action,知道了要做什么，那么方法 run()也就有知道如何去run了。

同时我还可以把(完成功能的)每一个页面作为一个对象来看待，所以我应该至少还需要两个类
class HelloPage 和
class DatabasePage
由于这两个对象最终都是向浏览器发送页面所以把他们共同的部分提出来作为他们的父类
class Page
以下是三个类文件的内容

class.Page.php

CODE:

<?php

class Page
{
function Page()
{

}

function show()
{
//不能直接调用这个方法一定要在子类中去具体实现。
die('You can not use this funciton directly from Page class');
}
}
?>;

其中这个show方法应该是所有页面对象都具有的方法，只是在实现上有所不同。

class.HelloPage.php

CODE:

<?php
require_once ("class.Page.php");

class HelloPage extends Page
{
function HelloPage()
{
parent::Page();
}

function show()
{
echo "Hello, I can say OOP in PHP world!";
}
}
?>;

class.DatabasePage.php

CODE:

<?php
require_once ("class.Page.php");

class DatabasePage extends Page
{
function DatabasePage()
{
parent::Page();
}

function show()
{
//做一些数据库操作然后将结果显示出来。
}
}
?>;

同时我们还遵守这样的一条规则：action的值和调用的页面类的名称保持一致，例如当action=HelloPage的时候程序就知道需要初始化一个HelloPage的对象，有了这样的规则和以上的几个文件我们就可以将 Application 类改进成这样。

CODE:

<?php

class Application
{
function Application()
{

}

function getAction()
{

}

function run()
{
$pageClass = $this->;getAction();
include_once ("class.".$pageClass.".php");
$page = & new $pageClass();
$page-&gt;;show();
}
}

?&gt;;

为什么getAction()空着？因为它太简单了，你自己可以轻松地把它写出来呀。

看到这里，如果你还不太明白，不用急，可以停下来重新再看一遍。

如果全明白了，我们就继续前进。我们还有半个任务没有完成，所以我们需要改进我们的Application和页面类，让它完成数据库操作功能。
进行数据库操作之前首先应当得到一个正确的数据库连接，如果让每个需要数据库连接的页面类去做这样的工作实在是一件非常费时费力的工作，不容易维护管理而 且也破坏了oop的设计初衷，进行数据库操作的页面类例如 DatabasePage 只应当完成它份内工作即获得数据。 仔细看看我们的设计不难发现建立数据库连接的工作交给 Application 来做最合适不过了， 所以给Application 增加一个新的成员 $db 并且在初始化的时候将建立的数据库连接赋值给它。

CODE:

<?php
require_once ("class.Database.php");

class Application
{
var $db;//数据库对象

function Application()
{
$this->;db = & new Database(DB_HOST,DB_NAME,DB_LOGIN,DB_PASS);//$db 现在是一个数据库对象了
}

function getAction()
{
return $_GET['action']; //简单的实现 getAction;
}

funciton & getDatabase()
{
return $this-&gt;;db;
}

function run()
{
$pageClass = $this-&gt;;getAction();
include_once ("class.".$pageClass.".php");
$page = & new $pageClass($this); //这里是唯一做了手脚的地方，将这个Application对象传给页面对象。
$page-&gt;;show();
}
}

?&gt;;

你现在不用太关心这个 Database对象从何而来如何实现，知道它是一个含有数据库连接的对象就可以了，如果用过phplib, ADODB,或者Pear库的就很容易理解。
这个语句：
$this-&gt;;db = & new Database(DB_HOST,DB_NAME,DB_LOGIN,DB_PASS);
就是建立一个数据库连接而已。

至于DB_HOST,DB_NAME,DB_LOGIN,DB_PASS 这些都是常量我们在config.php中已经预先设定。

由于数据库操作页面 DatabasePage 需要进行数据库连接所以它也需要一个变量 $db 来保存数据库对象，所以我们需要把DatabasePage改进成这样：

class.DatabasePage.php

CODE:

<?php
require_once ("class.Page.php");

class DatabasePage extends Page
{
var $db;

function DatabasePage(&$app)//将Application对象作为参数接受。
{
parent::Page();
$this->;db = $app-&gt;;getDatabase();//获得 Application 中的数据库对象。
}

function show()
{
$sql = 'SELECT * FROM sale_orders';//简单的一个 SQL 例子。
$results = $this-&gt;;db-&gt;;query($sql);//query 是 Database对象的一个公共的方法，通过它向数据库提交SQL查询。
...;//做一些操作把得到的结果显示出来。
}
}
?&gt;;

好 了，一个半的功能算是完成了，PHP对于OOP支持得也很漂亮吧，结构清晰，维护方便，至于效率嘛，我可没看出来有什么损失，如果你有兴趣可以自己测试一 下。用这样的框架可以轻松应对各种需求的变化：增加各种权限控制，分离数据库层，商业逻辑，和表象层，增加远程调用接口统统不成问题，只是这里实在写不完 这么多的东西。真不知道谁还会有理由说PHP 中OOP 很烂呢？

另外，需要提醒大家的是传递对象和赋值的时候要使用 & 符号这样可以保证每次引用的是同一个对象。