Techyou labs
真正的爱应该超越生命的长度、心灵的宽度、 灵魂的深度
常用标签

拖了两天,今晚终于有点时间来写下篇了。可是,对着电脑,却有点不知道从何说起。或许,就照着ZEND FRAMEWORK来说吧。当然,我会把握要点,记得这篇文章是以zend framework为例来阐述我对面向对象方式编程的认识,而不是一篇zend framework的入门手册,并且,这也不会是一个面向对象的入门教程,而是我对面向对象的理解。
一、统一入口文件
在很多人眼里,php仍然不能算是“完全”面向对象的,理由就是面向对象应该是所有程序要全部对象化,而PHP还留有一个入口文件。但这种学术上的争论,和我们其实是没什么关系的。我们只需要知道,作为一个完全面向对象的应用,除了index.php之外,所有程序都应该是以类的方式编写的。
在zend framework中,用到了rewrite技术,rewrite不仅利用伪静态功能吸引搜索引擎收录,还可以禁止index以为的PHP文件直接运行从而避免安全隐患。在joomla中,rewrite是可以在后台中选择的,即使是面向过程的项目,discuz 和phpwind也都提供了rewrite的选项,而在zend framework中,说起来可能会让很多zf的初学者呕血,其实用或者不用rewrite,是根本不需要配置的,只不过是链接的URL地址不同罢了。很奇怪的,似乎所有资料上都没有提及这一点,其实,我们完全可以在IIS下和绝大多数支持PHP的虚拟主机上使用zend framework而不必担心rewrite的问题。
当然了,我个人对rewrite技术还是非常拥护的,对我而言,这项技术至少有三个好处:1、用伪静态方式增加搜索引擎搜录;2、保护重要文件及危险文件不被运行和下载;3、用PHP生成图片文件时,其URL地址和真实的图片地址格式完全相同。
所以,一个好的面向对象程序,应该要统一入口文件,并用rewrite功能限制不合规范的其它php文件的使用。
二、MVC模式
MVC模式是一种非常经典的编程方式。我在本文的上篇就已经提过,如果纯粹追求执行效率,每个程序页面一个文件,才是最为高效的。但是人力有其极限,所以终究需要把文件切割开来,并按一定规律对文件进行归类。如果你做PHP足够久,应该见过各种五花八门的切割和文件归类方式,而其中,升华为模式并为主流所接受的,只有MVC。
如果说程序和页面分开,也就是view视图独立,已经为大家所公认,那么控制器和模型是不是要分开,很多人还是有不同意见的。一开始我也觉得,小项目里不需要这么讲究,但是不久之后就发现模型的好处了。模型在功能上很大程度与面向过程项目中的函数库相似,函数库的好处,我在本文上篇一开始久已经说过,这些理由同样适合与模型,功能总是应该被细分为函数的,MODEL只不过是对这些函数进行统一归类而已。模型与函数库的最主要区别,在于我们通常为每个数据表建立一个模型,这样,每个模型中的方法不至于过多,方法的命名也可以得到统一。比如函数库中,删除文章命名为delArticle(),删除图片命名为 delPicture(),删除用户命名为delUser(),而用模型一分开,统一都叫del()是不是整洁多了?
所以,无论项目大小,只要用到数据库,那么使用MODEL总是值得的。

一个值得商榷的问题是,从理论上说,model只负责数据处理,不负责输出显示的,而我之前的几个项目中,也规规矩矩的把输出放到了zend framework的视图助手中。但最近,我刚刚在model中直接建立了生成列表和目录树的方法,和视图助手相比,多少省了点时间,而且也没发现有什么坏处,所以,在没有发现问题之前,我会继续在model中做一些小量的输出:生成string,并返回给controller中的相关调用命令。现在想想,或许是我理解错误,也许资料中提到的MODEL不负责输出,只是要求不用echo等方式直接显示页面,生成string,或许本来就是允许的。
三、phpunit测试框架
在面向过程的编程中,很多人在需要时写函数,然后在需要调用函数处直接调用函数进行测试。可能很多人和我一样,某一天突然发现自己不能忍受各种意外因素的干扰,而新建了一个test.php来进行这些测试,而后,测试逐渐增加,test.php就改成了test文件夹,里面存放对所有函数的测试,这就是 phpunit的雏形了。在整个编程过程中,测试占据了我们大量时间,而phpunit保存了这些测试,节省了我们在日后修改类和方法时的大量测试时间。
四、类的抽象和继承
在我的代码中,一直在继承,而很少有抽象。抽象和接口对我们编写程序做了强制性的定义要求,所以,对于合作者不多的程序员来说,似乎没有太大的意义。但是,也正是由于编程过程中的自由散漫,往往会在事后然我们或是我们的下一任程序员尝到苦果。之前在开篇中我就提过,写这个帖子,是我对之前经验的反思过程,所以,在这里,我要说的是,之前我写的代码,是极少有抽象和接口的,而在以后的工作中,我将补上这一点,从而统一我对属性和方法的命名。
五、设计模式
迄今为止,人们共总结了23种设计模式,其中我用到比较多的有注册模式、工厂模式和单件模式。设计模式是对前人面向对象编程方法的总结,幸运的是,当我用 zend framework框架编程时,很多时候都并不需要太多了解它们的技术细节就能直接利用,比如注册类zend_register用到了注册模式,zend_form则大量采用了装饰模式,而反射API之类的技术,也都得到了合理的应用。当然,反过来说,zend framework的学习难度也因此增加,我们学习一门技术,往往不满足于知其然,而想知道所以然,而这些模式,显然不是一本手册所能涵盖的,ZEND FRAMEWORK之所以难于掌握,与我们对于设计模式等相关知识了解不深,有很大的关系。
六、框架
很多人对zend framework身怀恐惧,宁可去学习一些小型的轻量级框架,也不愿意接触zend framework,理由是,它太庞大了。事实上,我自己也为学习和应用zend framework而吃了不少苦,浪费了大量时间。最后,我终于幡然醒悟,框架改变了我们原先的编程思维,我们应该向手册和入门指南中说的那样去用框架,而不是坚持我们的习惯,改变框架来适应我们,否则必然事倍功半,得不偿失。比如,我最近写了一个网站http://www.10000j.com ,它的功能有这样几个:
1、显示http://happy.10000j.com论坛中投稿区中的所有文章分类列表和文章内容;
2、显示作者好友的所有投稿文章列表;
3、自动生成google的sitemap。
功能确实是相当少的,但连设计页面在内,基于zend framework完成这个网站,我一共只用了两天时间(而且还不是两个全天)。所以说,虽然号称重量级框架,zend framework对小型项目的开发确实是适合的。如果你觉得zend framework太大,你完全可以不使用那么多功能类库,掌握了哪些,就用哪些。zend framework的问题在于它的功能太多,不可能通过一个项目完全掌握,所以千万记得要循序渐进才行。
当然,其实我们也可以完全不用框架,而自己以MVC方式为主体编写面向对象程序,所以,我不能理解的,反而是那些轻量级框架的存在意义。如果一个框架只是一个MVC模式的架构器,那么,就像对smarty的困惑一样,我们为什么不自己直接来写呢?
比如可以这么来写:
index.php

<?php
$controller
=$_GET['controller'];
require_once 
'controller/'.$controller.'.php';

controller.php

require_once 'some_model.php';
$model=new Some_Model();
$string=$model->getString;
require_once 'templates/templte.phtml';

some_model.php

<?php
class Some_Model extends PDO{
     public function getString(){
           $string='hello world!';
            return $string;
    }
}

template.php

<html>
......
<body>
<?php echo $string;?>
</body>
</html>

这样,MVC模式的面向对象程序就成功创建了吧?
当然,这个只是我随手打的例子,我买过本书叫《PHP高级程序设计:模式、框架与测试》,里面有一个自制轻量级框架的演示,比我这个要好得多。所以,我感觉那些轻量级框架,似乎没有什么存在的价值。而zend framework则不同,它的庞大类库事实上是制定了一个标准,回忆一下我们到现在,究竟换过多少类库?数据库类、分页类、缓存类、文件上传类.......在一个应用中用到,而在下一个应用中就往往因为功能要求不同、原作者停止更新甚至是不记得原来的下载地址、或是自己写的类想法有了变化重新再写一个等等理由,而更换成了另一个类。每个类看似不大学习成本不高,加到一起就不容小视了。而采用zend framework框架,哪怕只用它来做类库,总不至于那么快就淘汰掉,而且大公司出品,总能更让人用着放心。
所以,面向对象的程序,我以后还是会基于zend framework来写。
以上是我对PHP语言面向对象编程的一些看法,才疏学浅,权做抛砖引玉,请大家指正。

暂无评论

添加新评论