在Java编程中的“模式思想”与框架关系

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

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

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

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

GoF模式打开的新境界

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

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

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

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

非模式思维的惩罚

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

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