呵呵，意犹未尽，继续批驳。
banq先生对自己的思维和真正想法并不是了然于胸，我想他不关心的是业务逻辑的实现了，他说他已经很多年不去翻J2SE了，那是因为他已经很多年不是“程序员”了，他不需要使用他的框架去完成一个实际的业务系统，你把这个框架做了，你鼓动别人去使用框架，去学习设计，还有意义吗？如果别人都去提高学习了，都去设计了，就不会有人用他的框架，而如果别人都不用，那他搞那个框架又是为了什么呢？
他说他自己对J2SE都忘记了，那么他是如何完成这个基于Java的框架的？难到都是拷贝别人的代码，然后就是debug？

再说他所谓的向上思维和向下思维，其实不是思维问题，而是开发方法问题，他所谓的向上思维是敏捷开发所推崇的，自底向上实现系统，发现问题就不断的重构系统，而CMM/CMMI以及RUP之类的开发方法就崇尚自顶向下实现，也就是他所谓的向下思维，这些方法的优劣现在本身就没有定论，也不会有定论，需求的不同导致使用不同的开发方法有不同的效果，IBM之类的大公司接单子都是预先浪费了无数的时间确定需求，然后签合同，完全按照合同的内容来执行，他们有资格使用自顶向下设计；而广大的中小软件公司没有那个本事，可怜兮兮的拿下一个单子也只能当孙子，客户让怎么改还不是怎么改？能拿到钱就不错了。所以这些公司使用自底向上就很自然了，因为快捷简单，能够更好的应付需求的变化（当然，要做好也非常的不简单）。

“一个新技术不必关心它是如何做出来的，而是重点研究是如何使用它，使用的场合和条件是什么，这些就是模式啊”，天啊，这个是模式吗？模式是程序内部的设计好不好！怎么会和技术的使用场合和条件扯上关系呢？

“如果我说不学习"数据结构,操作系统,编译原理,数学"，照样可以作出架构优质的高性能Java系 统，你可能不惊奇了，Collection和数据库技术已经就是依据数学结构做出来的，你学了数学结构，自以为懂了很基础知识，碰到 COllection，你就会自然去打开看看，自豪运用你的数学结构理解它一番，可是这些对于你如何使用COllection根本是两个领域的知识(如何 使用Collection是模式领域知识)，这些都是先入为主造成浪费时间，能力不足的表现”
呵呵，他的那个叫做“作出”的吗？据我所知充其量是拼出来的，系统最核心的部分都是别人的（当然，这个也不惊奇，因为他最自豪的就是可以看懂别人的设计和使用别人的成果），当然不需要数据结构了。学习Collection的实现会浪费时间吗？看这个对于设计能力难到没有提高吗？看别人的设计就是能力不足了，想想自己当初是怎么学习设计模式的！
算了，不说了，记得原来gigix就写过一篇文章批驳过他的。

呵呵，看到JDon上正在讨论j2se基础的重要性，忍不住也来说两句，可以这么说，我是完全反对banq的说法的。
我不知道banq的功底到底如何，但是对于指导初学者，我觉得他完全不合格。
编程，在大多数情况下是简单的，这个可以从印度大量使用高中生编程照样可以开发出稳定大型的系统可以看出来，而且以我的经验来看，做对日外包也是一样，因为他们的设计文档已经写得足够的详细，他们提供的底层框架已经足够傻瓜（和设计文档相配合），在这种情况下，编程并不需要太多的技能，显现水平的方式就是对框架API和底层API的熟练程度，熟悉了那些API差不多就可以了（而且本来就有详细的API文档），只要可以编译通过，基本上就是验证业务逻辑是否符合需求的问题，再拔高一点，万一框架出现问题，是否有能力解决问题，这个就是全部了。
而banq先生才是恰恰误导了广大的初学者，把编程和设计混为一谈，banq先生一直考虑的都是上层的事情，都是架构和框架方面的内容，这个不是所有的程序员需要掌握和有机会掌握的，我看得太多的程序员工作了好多年，但是对于如何设计一个完整的系统还是一无所知，当然这个也不能全怪程序员，因为这个社会的大部分分工都是金字塔型的，顶层的人员的需求总是少数的，也永远只有少数人有机会去一探上层的内容。

回到编程，banq先生说OO是自然的，这个绝对是荒谬的，一个人做事情，他是按照一定的工序做的，这就像流水线一样，所以在完成简单工作的时候，OP才是自然的，你查看任何OO的系统，系统中把OO连接起来的那些代码绝对是OP的，只是这个过程，是代理给一些对象完成的，但是总归会回到主流程，为什么Java需要一个main方法？因为这个是这个过程的开始点。计算机处理程序也永远是过程式的，计算机不会理解对象，也不会理解对象之间的关系到底是怎么样的？那么为什么现在OO流行呢？因为OP在处理复杂系统的时候力不从心，这个是一个人为的提升过程，其实就是将OP中相关的方法和变量进行更好的封装，增加了一些OP所没有的特性（继承，信息封装），这样，我们在完成复杂系统的时候，代码的关系更加的清晰，我们也不用在程序执行的过程中声明太多的变量，也不用把一个过程定义得太复杂，OP这个过程中需要使用到得信息和方法被切分成很多独立的对象了，外围的程序通过调用这些OO的内容完成原来的OP的同样过程或者类似的过程。OO并不是最近才出现的，而是很早就出现的，可能和OP的出现一样早，为什么OP先流行呢？因为它“自然”简单，从头到尾一目了然，为什么OO那个时候没有流行起来，因为它理解起来比较别扭，而早期的计算机系统处理的任务都非常的简单，很多都是完成数学计算的。而计算机的速度越来越快以后，我们让计算机做的事情越来越多，越来越复杂，这样的系统的设计实现使用OP来做已经很难维护了，使用OO的方法就可以把系统切分开，很多人完成，定义相互之间的关系，然后使用OP的机制把他们连接起来达到我们的目的。

以装修为例，古代的装修很简单，可能就是编个挂毯挂上就行，任务的完成过程很简单，现在的装修呢？需要监理、水电工、泥工、木工、油漆工等等，监理负责任务的调度，什么时候水电工到场，做到那个程度，然后泥工做什么，木工做什么，在这个过程中，工种之间还需要协调配合，如果把所有的这些都丢到工地上（材料、人员和工具），会是一个什么样的局面？假设我们那么做了，可能工程还是可以完工，但是这个风险要比经过良好调度和分配的过程大得多。材料就好比对象的属性，人就好比对象，工具就好比私有方法，而他干的工作类型就是公共方法（例如木工做一个柜子，做门套，泥工拼地砖墙砖），监理就好比外围的程序（有时候监理也是对象，如果从房东的角度看的话，只是他需要的材料就是那些“工人”，对外的公共方法就是装修完，也有状态查询方法），监理关心的是人的调度以及让他干什么，而人知道怎么完成自己分内的工作，怎么用自己需要的材料和工具。