PHP+Java的开发经验：不要太面向对象

guoln

说起面向对象，现在很多语言多少都有一些。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那样随时修正文件随时生效。为了不中缀效劳，我通常选择做个集群，轮流发布。这样虽然仍旧有能够产生一些成绩，但比中缀应用好多了。可是集群会带来发布上的费事，集群自身也未必是我真正需要的。 随之而来的还有一些小成绩，比如假如我项目中包括一些存储大量文件的文件夹，在发布的时分又要特别处置，这样很不爽。即使做软链接，发布时也免不了要做额定任务。这些成绩，当然我想信会有更好的处置办法，我个人目前仍在探索中。 面对上述这些成绩，我最终不再坚守面向对象。ifsong旗舰店我把项目改成了前PHP后JAVA的形式。PHP做前端显得灵活多了，整个改版，PHP的逻辑部分没花多少工夫，工夫都用在了页面设计上；JAVA的后端又能保证动摇高效，易于平安设计。由此，我最终收回了“不要太面象对象”这一感叹。需求决定一切，跟着他人的思想走，跟入邪教没区别。 成绩也还并没有结束，对JAVA后端部分，我还在探索一个基于插件式的可以热加载、缷截插件的CMS后端系统。呵，不能由于下面的缘由把面象对象一棒子打死。 不过不论怎样，看了作者的描绘，倒是无妨试试PHP+Java的组合：看看放弃一些面向对象可以带来些什么好处吧。