Heim  >  Artikel  >  Backend-Entwicklung  >  PHP+Java的开发经验:不要太面向对象_PHP教程

PHP+Java的开发经验:不要太面向对象_PHP教程

WBOY
WBOYOriginal
2016-07-15 13:26:27813Durchsuche

说起面向对象,现在很多语言多少都有一些。Java是传统的面向对象语言,PHP也有一些面向对象,但不是很好。完全的面向对象在具体的项目中(本文是Web开发项目),有时候其实并不是最好的选择。本文作者最终选择了PHP+Java的一个模式,并分享了一些自己的经验。

我较早接触了C++(高中),也较早接受了面向对象思想。面向对象思想更接近人的思考方式,其封装、继承等特性也常常能够简化一些工作,最重要的是思路看起来清晰多了。我对面向对象的思想深信不疑,直到有一天,我在WEB项目中陷入困惑。

我以前的工作也都是WEB开发相关的,通常项目里都是接口、实现,service层,DAO层这个样子。久而久之,就习惯了这种模式。后来,我开始自己做网站(自己运营),也沿用这种模式,花了一阵子时间把东西弄出来,可以跑了,问题也随之而来了。大家都知道,类似门户网站这样的东西,尤其是成长期的网站,可能会经常面对一些变更、扩展。它不像企业项目或是以稳定模式运营的网站,可以一套写好的程序一直用下去。可是JAVA的东西改动起来有点麻烦。

第一:项目里用了很多接口,业务变更有不少时候还要动接口。也许有人会说,这是因为需求没做好。是的,可以这么认为,但有个前提:需求根本没法一步到位,否则网站也别跑了,等需求分析做好,花都谢了。回忆一下这个经典的流程:要增加一个特性(页面部分暂不讨论),先增加或修改一个service接口;然后增加或修改其实现;接着视需要可能还要再增加或修改一个DAO层接口,对应的要增加或修改其实现;最后,我们真正要改的,往往只是一个SQL语句。

这一系列流程太过繁琐了。门户网站基本是展示信息的,它的业务逻辑,说到底基本上是SQL语句体现出来的。你想想看,网站上显示什么东西,怎么排序,怎么聚合,这些不都对应着相应的SQL语句么?如果你非要把DAO层写成基本的增删改,然后在service层大作文章去实现本来对应着一个SQL语句的业务罗辑,这有什么意思呢?纯粹为了分层而分层?为了面向对象而面向对象?更不用说那一堆接口,平白增加工作量。我当然不会否认接口在编程思想中的意义,只是传统的JAVA WEB编程中的那一堆接口,是否真正是一个合理应用呢?我看很多情况下不是。我后来用PHP重写我的项目中的一大部分功能,只用了几天的时间,没有分层,没有接口。这样带来的工作效率的提升,真是惬意!

第二:JAVA WEB项目的发布通常需要重启服务,造成WEB运行中断。不少人在讨论热部署,我不知道热部暑最终能达到怎样一个水平,但我想信无法达到像PHP那样随时修改文件随时生效。为了不中断服务,我通常选择做个集群,轮流发布。这样虽然仍旧有可能产生一些问题,但比中断应用好多了。可是集群会带来发布上的麻烦,集群本身也未必是我真正需要的。

随之而来的还有一些小问题,比如如果我项目中包含一些存储大量文件的文件夹,在发布的时候又要特别处理,这样很不爽。即使做软链接,发布时也免不了要做额外工作。这些问题,当然我想信会有更好的解决办法,我个人目前仍在探索中。

面对上述这些问题,我最终不再坚守面向对象。我把项目改成了前PHP后JAVA的形式。PHP做前端显得灵活多了,整个改版,PHP的逻辑部分没花多少时间,时间都用在了页面设计上;JAVA的后端又能保证稳定高效,易于安全设计。由此,我最终发出了“不要太面象对象”这一感叹。需求决定一切,跟着别人的思想走,跟入邪教没区别。

问题也还并没有结束,对JAVA后端部分,我还在探索一个基于插件式的可以热加载、缷截插件的CMS后端系统。呵,不能因为上面的原因把面象对象一棒子打死。

不过不管怎样,看了作者的描述,倒是不妨试试PHP+Java的组合:看看放弃一些面向对象能够带来些什么好处吧。


www.bkjia.comtruehttp://www.bkjia.com/PHPjc/446594.htmlTechArticle说起面向对象,现在很多语言多少都有一些。Java是传统的面向对象语言,PHP也有一些面向对象,但不是很好。完全的面向对象在具体的项目...
Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn