在Java编程中的模式思想与框架关系的几个误区

目前在开发领域中各种框架越来越多;模式使用机会性似乎减少了,那么是不是意味着我们就不必掌握模式了呢?其实,学习模式实际为了培养模式思维,模式思维有助于了解和使用框架。

例如如果我们在使用表现层哪个框架,都是MVC模式实现,那么进行编程步骤时,我们脑海里就浮现一个步骤V/C/M以及C和V的转发关系,进而感觉struts-config.xml配置就不是多余或复杂,而是必须的。

现在有人觉得好像Java世界框架特别多,异常复杂,其实这可能是他从封闭世界走向开放自由世界产生的错觉,当你具备模式思维时,实际你就具备了挑选各种各样框架的能力,打个比喻:以选择轿车为例子,过去,只有一种“红旗”轿车供选择,你就只有接受这个轿车;但是现在轿车多了,选择多了,你就必须了解轿车的通用概念,进而你就可以在各种轿车之间选择和衡量,了解轿车的通用概念这个过程就如同我们学习模式,具备通用编程的模式思维,有了模式思维,就会发现有这么多选择产品,不再嫌复杂,而是变得兴奋了;所以,没有复杂的东西,只有是否原意学习的头脑;PC电脑对于一些人很复杂,可是对于我们会复杂吗?不会,因为我们已经掌握通用电脑的模型、模式。

所以,有人觉得Java软件很多配置复杂,甚至产生配置恐惧症,那是因为他没有模式思维,在模式思维指导下的编程工作,就象在写一篇生动的小说一样,你脑海展现的生动模式实现步骤,而无论代码或配置都是实现你模式思维的文字工具,模式思维考虑到哪里,就想起什么配置,配置对具备模式思维的你来说是很自然的表达。

在模式思维下的Java编程,编码阶段code completion可能花费2/3时间,但是调试测试时间只需要1/3甚至不到,大多数情况下是一步到位的调试成功;这比以前1/3编程时间,2/3调试时间要高效多,关键是:你无论花费多少时间在调试上,实际上是在做一个修修补补的工作,是在做维修工,头疼医头,永远是机修工,无法成为设计师。

下面从模式思维角度谈谈几个认识误区,仅仅参考讨论:

游戏软件比企业软件复杂?

为什么说企业软件时复杂的?因为企业软件是为应付需求而变,与游戏软件等软件相比,虽然一个游戏软件在代码数量级别上比企业软件复杂,但是游戏软件不必考虑跟随游戏用户需求变化,是游戏用户服务游戏设计规则;但是企业软件和其用户则相反,企业软件必须服从用户的变化,打个不是很确切的比喻:企业软件则类似市场经济中的市场人员,需要“看客户脸色”行事。而游戏软件则相反,类似以前朝南坐的政府人员;

因此,企业软件在动态概念上是随时间变化而变化,是由生命的,因为计划赶不上变化,所以企业软件制作时总是使用模式为将来变化预留余地,这种面向未来变化考虑方式无疑是最复杂的思维,就象股票变化将这种未来变化的残酷推向极致,我们都想计划未来,但是总是计划不了未来,这就是企业软件的复杂所在。

Class.forName神秘吗?

有人觉得Class.forName很神秘,神秘不在于本身,就是打开其编码研究到二进制也不能达到目的,它的神秘之处是因为应用在一个恰当之处,就象一块普通布没什么,但是如果从后面变出花了,你觉得这块布神奇了,Class.forName神奇之处在于其隐藏了对象创建,也一种是工厂模式实现。

同样,对于Collection,本来就是那几个种类List和Map,但是发现使用起来神奇得很,有人甚至研究过Collection的二进制,这和研究魔术师中一块普通布没有什么区别。Collection用于容器,作为对象集合;以及和单例结合实现缓存等,可以实现多种模式。

仅会算法就做企业软件吗?

在实践中,通常表示一个树形关系通过编码实现,例如1122334455表示是代号为11类别下代号为22类别下的代号为33类别下的....然后,在软件各处通过分析这个类别编码获得树形关系,这种将将具体数据和业务耦合在一起做法是受到抨击的。

那么如果我们要对树形关系的数据进行访问如何实现呢?首先我们将树形关系的访问分为两个部分:树形关系+功能实现。我们已经知晓树形结构的遍历,但是仅仅知道树形结构遍历还是不够的,我们还需要模式来解决树形关系访问这个通用问题,使用Composite模式可以方便客户端对树形结构访问,使得客户端不至于因为树形结构变化而变化不定;而访问者模式则不会总可能新增的新访问功能,导致树形结构中对象代码变化不定。

这两种模式协同发力,可以综合解决树形结构中对象群的访问。

GoF模式打开的新境界

没有知晓GoF模式之前,我们总是以为编码就是写一些代码,然后运行,复杂吗?如果我们来分析一下GoF模式三个类型,你会发现平时熟视无睹的代码中隐藏如此多考虑方面。


GOF模式三种类型:结构型模式、创建型模式和行为型模式其实函括了OO编码的三个方面:静态类关系、类创建成为运行时对象实例;运行时的对象运行行为,也就是说,我们在编码阶段不但考虑现阶段各个类之间静态解耦关系,而且还要考虑这些代码激活后,运行时的情况。


而以往过程化编程中,编码状况=运行状况,如何先后编码,这些编码运行时就按照这些先后编码顺序执行,两者是统一的,不可能出现运行时可能和编码时预想不一样,更何况需要我们还要在进行类编码时,考虑这些类运行时是如何实现的,有如何对这些类运行时的关系进行解耦和分离呢?所以,我们“天生”就无法理解设计模式,因为我们从来就认为软件就是实现功能,哪里还会考虑到实现同样功能会涉及各种考量了呢?

如果说设计模式是程序员的圣经,那么不掌握设计模式可能就是异教徒,从此教徒和异教徒两者之间就缺乏沟通对话平台,就象鸡对鸭讲话了。

非模式思维的惩罚

面向对象软件体系是和面向过程体系格格不入的,面向对象的各种技术如单元测试 性能缓存等等都是OO体系,如果我们没有具备模式思维来编程,由此而诞生的软件架构必然失败,失败在哪里?通过性能惩罚你。最近碰到一个台湾的钢铁架构,它虽然包含一个简单的MVC框架,但是其Controller实际又是Service,该框架配置将下面几个元素耦合在一起:页面流程;控制类;Dao与VO,这实际是将表现层和持久层直接结合一起,这样的框架迫使程序员没有空间做中间领域模型层和服务层,进而整个体系变成一个两层耦合结构,这和传统的C/S没有区别,在Java中使用传统概念编程:如面向过程、面向数据表以及两层耦合导致结果是性能缓慢,很多大型项目就是这样最后是毁在性能上,服务器需要经常启动,一旦并发用户就很慢,服务器经常死机。

有人可能奇怪:非模式思维属于设计问题,怎么会对性能影响,这是将设计和性能对立起来,性能也是一种设计,池模式以及缓存也是属于模式啊,但是缓存的高效率应用是建立良好的对象设计基础上,或者说是良好的领域建模上,否则就是使用缓存,也会导致粒度或动态机制不准确,无法发挥缓存效率,甚至无法使用缓存。

您的回应...

相关话题

查看全部

也许你感兴趣

换一批

热门标签

更多