JavaEE架构上的思考

许是我孤陋寡闻吧,我知道Java是面向对象思想的,我也知道Web项目很多都采用MVC架构以及三层架构什么的……

但是,这架构本身与面向对象思想是相背离的!

面向对象思想绝不是"调用任何方法前都要使用对象打点的形式",而是"充分的抽象、利用多态的方式重用代码"

然而在进入到实际工作中我发现,在经典的架构上使用面向对象思想几乎是不可能的。

第一,快速。

不是指的代码运行速度上的快速,而是指开发速度。项目刚开始的时候总是时间紧迫,要快速开发,需求什么的当然有,也都会把工作做好,可是真正投入到工作中之前,谁都不会明白真正的需求是什么。

为了快速开发,Spring自动装载的时候,我们只会去装载一个impl,不会尝试装载多个,甚至没机会去编写另一个impl作为传说中的"候补方案"

这当然有它的好处,毕竟直线逻辑是我们所有人都最容易理解的,这样直线写下来,比一层套一层的接口+实现更容易理解

而作为代价,当业务发生扩展时,我们只能在原来的代码上修修补补,很快就出现了一层又一层的if……这时候再转,你们都懂得,重构是怎样一个可怕的工作——尤其是这并非局部的重构,而是整个项目的重构。

第二,框架。

依据分层原理,一层和数据库打交道,我没记错的话它叫DAO,一层处理业务逻辑,叫Service,一层和页面打交道,叫Action

其中Service层要处理大量的业务逻辑,面向对象想要重载的话,就得从Action中调用各种不同的Service实现

然而,Action是单例的,它只应当Autowired一个Service,这就失去了面向对象的意义

或许"候补方案"的意义仍然存在吧,但我认为这实在不如从SVN上拉个分支出去

想要解决这个问题,这是架构上的问题,就得从架构上解决。

为了快速开发,前期的代码逻辑必然是直线结构,只有当业务出现分支时才开始变复杂

这样,框架就得将"不同的Service实现"这玩意隐藏在框架内部

我知道Spring的Autowire可以择定某一个特定的实现,但我却没想清除该如何将这个功能与面向对象思想联系起来

总之,在Action中Autowire同一个Service的不同实现这样的做法简直不可理喻

依然在想,嗯……想清楚了再说。