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