PHP编程方式的重新思索(下)

拖了两天，今晚终于有点时间来写下篇了。可是，对着电脑，却有点不知道从何说起。或许，就照着ZEND FRAMEWORK来说吧。当然，我会把握要点，记得这篇文章是以zend framework为例来阐述我对面向对象方式编程的认识，而不是一篇zend framework的入门手册，并且，这也不会是一个面向对象的入门教程，而是我对面向对象的理解。    

02    一、统一入口文件    

03    在很多人眼里，php仍然不能算是“完全”面向对象的，理由就是面向对象应该是所有程序要全部对象化，而PHP还留有一个入口文件。但这种学术上的争论，和我们其实是没什么关系的。我们只需要知道，作为一个完全面向对象的应用，除了index.php之外，所有程序都应该是以类的方式编写的。    

04    在zend framework中，用到了rewrite技术，rewrite不仅利用伪静态功能吸引搜索引擎收录，还可以禁止index以为的PHP文件直接运行从而避免安全隐患。在joomla中，rewrite是可以在后台中选择的，即使是面向过程的项目，discuz和phpwind也都提供了rewrite的选项，而在zend framework中，说起来可能会让很多zf的初学者呕血，其实用或者不用rewrite，是根本不需要配置的，只不过是链接的URL地址不同罢了。很奇怪的，似乎所有资料上都没有提及这一点，其实，我们完全可以在IIS下和绝大多数支持PHP的虚拟主机上使用zend framework而不必担心rewrite的问题。    

05    当然了，我个人对rewrite技术还是非常拥护的，对我而言，这项技术至少有三个好处：1、用伪静态方式增加搜索引擎搜录；2、保护重要文件及危险文件不被运行和下载；3、用PHP生成图片文件时，其URL地址和真实的图片地址格式完全相同。    

06    所以，一个好的面向对象程序，应该要统一入口文件，并用rewrite功能限制不合规范的其它php文件的使用。    

07    二、MVC模式    

08    MVC是一种非常经典的编程方式。我在本文的上篇就已经提过，如果纯粹追求执行效率，每个程序页面一个文件，才是最为高效的。但是人力有其极限，所以终究需要把文件切割开来，并按一定规律对文件进行归类。如果你做PHP足够久，应该见过各种五花八门的切割和文件归类方式，而其中，升华为模式并为主流所接受的，只有MVC。    

09    如果说程序和页面分开，也就是view视图独立，已经为大家所公认，那么控制器和模型是不是要分开，很多人还是有不同意见的。一开始我也觉得，小项目里不需要这么讲究，但是不久之后就发现模型的好处了。模型在功能上很大程度与面向过程项目中的函数库相似，函数库的好处，我在本文上篇一开始久已经说过，这些理由同样适合与模型，功能总是应该被细分为函数的，MODEL只不过是对这些函数进行统一归类而已。模型与函数库的最主要区别，在于我们通常为每个数据表建立一个模型，这样，每个模型中的方法不至于过多，方法的命名也可以得到统一。比如函数库中，删除文章命名为delArticle()，删除图片命名为delPicture()，删除用户命名为delUser()，而用模型一分开，统一都叫del()是不是整洁多了？    

10    所以，无论项目大小，只要用到数据库，那么使用MODEL总是值得的。    

11    一个值得商榷的问题是，从理论上说，model只负责数据处理，不负责输出显示的，而我之前的几个项目中，也规规矩矩的把输出放到了zend framework的视图助手中。但最近，我刚刚在model中直接建立了生成列表和目录树的方法，和视图助手相比，多少省了点时间，而且也没发现有什么坏处，所以，在没有发现问题之前，我会继续在model中做一些小量的输出：生成string，并返回给controller中的相关调用命令。现在想想，或许是我理解错误，也许资料中提到的MODEL不负责输出，只是要求不用echo等方式直接显示页面，生成string，或许本来就是允许的。    

12    三、phpunit测试框架    

13    在面向过程的编程中，很多人在需要时写函数，然后在需要调用函数处直接调用函数进行测试。可能很多人和我一样，某一天突然发现自己不能忍受各种以外因素的感染，而新建了一个test.php来进行这些测试，而后，测试逐渐增加，test.php就改成了test文件夹，里面存放对所有函数的测试，这就是phpunit的雏形了。在整个编程过程中，测试占据了我们大量时间，而phpunit保存了这些测试，节省了我们在日后修改类和方法时的大量测试时间。    

14    四、类的抽象和继承    

15    在我的代码中，一直在继承，而很少有抽象。抽象和接口对我们编写程序做了强制性的定义要求，所以，对于合作者不多的程序员来说，似乎没有太大的意义。但是，也正是由于编程过程中的自由散漫，往往会在事后然我们或是我们的下一任程序员尝到苦果。之前在开篇中我就提过，写这个帖子，是我对之前经验的反思过程，所以，在这里，我要说的是，之前我写的代码，是极少有抽象和接口的，而在以后的工作中，我将补上这一点，从而统一我对属性和方法的命名。    

16    五、设计模式    

17    迄今为止，人们一共总结了23种设计模式，其中我用到比较多的有注册模式、工厂模式和单件模式。设计模式是对前人面向对象编程方法的总结，幸运的是，当我用zend framework框架编程时，很多时候都并不需要太多了解它们的技术细节就能直接利用，比如注册类zend_register用到了注册模式，zend_form则大量采用了装饰模式，而反射API之类的技术，也都得到了合理的应用。当然，反过来说，zend framework的学习难度也因此增加，我们学习一门技术，往往不满足于知其然，而想知道所以然，而这些模式，显然不是一本手册所能涵盖的，ZEND FRAMEWORK之所以难于掌握，与我们对于设计模式等相关知识了解不深，有很大的关系。    

18    六、框架    

19    很多人对zend framework身怀恐惧，宁可去学习一些小型的轻量级框架，也不愿意接触zend framework，理由是，它太庞大了。事实上，我自己也为学习和应用zend framework而吃了不少苦，浪费了大量时间。最后，我终于幡然醒悟，框架改变了我们原先的编程思维，我们应该向手册和入门指南中说的那样去用框架，而不是坚持我们的习惯，改变框架来适应我们，否则必然事倍功半，得不偿失。比如，我最近写了一个网站，它的功能有这样几个：    

20    1、显示论坛中投稿区中的所有文章分类列表和文章内容;    

21    2、显示作者好友的所有投稿文章列表;    

22    3、自动生成google的sitemap。    

23    功能确实是相当少的，但连设计页面在内，基于zend framework完成这个网站，我一共只用了两天时间（而且还不是两个全天）。所以说，虽然号称重量级框架，zend framework对小型项目的开发确实是适合的。如果你觉得zend framework太大，你完全可以不使用那么多功能类库，掌握了哪些，就用哪些。zend framework的问题在于它的功能太多，不可能通过一个项目完全掌握，所以千万记得要循序渐进才行。    

24    当然，其实我们也可以完全不用框架，而自己以MVC方式为主体编写面向对象程序，所以，我不能理解的，反而是那些轻量级框架的存在意义。如果一个框架只是一个MVC模式的架构器，那么，就像对smarty的困惑一样，我们为什么不自己直接来写呢？    

25    比如可以这么来写：    

26    index.php    

27    

28    view plaincopy to clipboardprint?    

29    

30 $controller=$ _GET['controller'];

31 require_once 'controller/'.$controller.'.php';

32

33 $controller=$ _GET['controller'];

34 require_once 'controller/'.$controller.'.php';

35

36 controller.php

37

38 view plaincopy to clipboardprint?

39

40 require_once 'some_model.php';

41 $model=new Some_Model();

42 $string=$model->getString;      

43    require_once 'templates/templte.phtml';     

44    

45 require_once 'some_model.php';

46 $model=new Some_Model();

47 $string=$model->getString;    

48    require_once 'templates/templte.phtml';    

49    

50    some_model.php    

51    view plaincopy to clipboardprint?    

52    

53 class Some_Model extends PDO{

54 public function getString(){

55 $string='hello world!';

56 return $string;

57 }

58 }

59

60 class Some_Model extends PDO{

61 public function getString(){

62 $string='hello world!';

63 return $string;

64 }

65 }

66

67 template.phtml

68

69 view plaincopy to clipboardprint?

70       

71    ......      

72          

73          

74          

75         

76        

77    ......    

78        

79        

80        

81        

82    

83    

84    这样，MVC模式的面向对象程序就成功创建了吧？    

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

86    所以，面向对象的程序，我以后还是会基于zend framework来写。    

87    以上是我对PHP语言面向对象编程的一些看法，才疏学浅，权做抛砖引玉，请大家指正。    

 以上就是PHP编程方式的重新思索(下)的内容，更多相关内容请关注PHP中文网（www.php.cn）！