从面向过程到面向对象再到UML来看待英语学习，思想才是王道

开篇两个引子：

引子一：

经常和一些编程人士交流，从他们的对话中能感觉到他们都是用着面向对象工具，用着面向对象程序语言，但是往往做不出一个真正符合面向对象思想的软件。

到底是为什么？而自己将来要做什么才能编写符合面向对象思想的软件呢？

引子二：

暑假我们团队进行了short brain英语培训，简单的说这种英语的学习就是推翻了以前几乎所有的英语学习模式，建立了一种在IT环境下的short brain英语学习模式。第一、二阶段主要进行的是利用IT将声音图像建立联系，达到一种short拼写和翻译的过程。

我们为什么要这样进行呢？

如题：

先说面向过程。

过程，过程，我认为就是有始点也有终点；从始点到终点因果的过度。这种程序设计方法的不好之处在于它的每一个部分都是那一条链子上不可分割的东西，牵一发而动全身。

大家也都知道，世界上唯有变是不变的，所以需求会变化。一旦需求变化了，那么用面向过程设计方法编写的程序就是出现意想不到的结果。

举自己以前的一个例子来说：以前自己做机房收费系统（vb6.0编写）的时候，就是按照面向过程的方法进行编写代码的，但是当我想把一个地方改掉的时候，便随而来的就是很多地方要跟随改动，甚至有时候会增加N多个bug。

所以第二次编写机房收费系统就不再用面向过程的方法进行编写了，至于原因不是面向过程实现不了（相反其实所有的程序利用面向过程的方法都能实现），而是它有时候在应对需求变化的时候总是显得有些“笨拙”。

再说面向对象。

对象，对象，我个人认为就是将我们接触到的东西看作一个个相互独立的对象，它们相互之间并没有因果关系，只有在某个外力的驱动下，对象之间才会打破这种“老死不相往来”的尴尬局势。学习了UML之后知道，这个外力驱动就是我们参与者Actor的愿望和希冀（正所谓的用例驱动也）。

我个人认为面向对象的编程目的绝不是为了复用，而是对象提供了我们一种处理和应对复杂问题的方法，我们可以通过抽象（提高抽象层次）来构建超级复杂的系统，而且当需求变化的时候我们不至于变得那么纠结难耐。

面向对象中其实最困难的还是抽象，抽象不应该是拍脑门就出来的东西，而是要用一种东西来描述，这个东西就是UML。

说道UML。

UML很好的解决了描述抽象的问题。它何以将现实世界映射到对象世界，可以从对象世界描述现实世界，当然它也可以验证对象世界和现实世界映射正确性。

这里就可以解决引子一的问题，为什么我们用了面向对象的工具和语言但是编写不出来一款真正的面向对象的软件，其实是UML没有用好。

大家都知道，UML是一种可视化的建模语言。既然是语言那么它就会有相应的基本词汇和语法。所以UML里面定义了一些建立模型所需要的、表达某种特定含义的元素（即词汇），还定义了一些这些元素之间关系的规则（即语法）。有些人以为会了这些词汇和语法就会很好的利用UML建立出面向对象的软件了！

其实不然，我们都知道象棋艺术中，不是认识了十六个棋子和会“马走日象走田炮打一溜烟车扫一横线”就是象棋大师了。我们也知道我们即使是利用同样的语言、同样的文字、同样的语法，每个人写出来的文章也是“天差地别”的。

所以要学好UML。我想肯定也会有人问该怎样学呢？这个问题的答案和引子二的问题的答案我认为是一样的。

顺接IT下的SB英语培训

为什么我们要进行sb培训，其实答案就是从面向过程到面向对象的转变。我们以前的英语学习模式都是背单词，背语法（类似有些人的UML学习吧！），之后考试。说英语一直都不是我们的强项吧？不是说以前的英语方法不能将英语学好，而是说以前的英语学习方法达到的效果和我们所付出的时间和精力不成正比。

鉴于以前英语学习模式不符合我们的需求，所以我们团队老师让我们进行了IT环境下SB英语学习。这种方法打破了传统，现在团队中的每个人都感觉这种方法很好。革命还未完成，战士们都在努力着。

所以我们学习UML不能光关注词汇和语法，要由对工具的使用上升到思想的高度，从而能够自如的跳出工具使用的局限，真正的从方法和思想的高度来看待和解决现实的问题。

不管是面向过程到面向对象，不管事学习UML还是英语，习技固然可以成为人杰，而悟道才能羽化升仙。

思想才是王道。