我今天看到了一篇文章，有关有些对UML学习的评论，最后得出一个买椟还珠的结论。我深受感触啊。
我一直都是在学习和计划系统学习软件工程，可能在老师的启发下，从大一下学期就开始学习软件工程（我至今记得那本书的名：《面向对象的系统分析与设计》），当时正时学正学C++，应该说是面向对象的设计和分析，那老师特好，大半的时间都在讲面向对象的分析和设计,以及个人曾经辉煌的历史，只花很少的时间讲C++,当时虽然很多人都不习惯，我却听得很受用。这对我学习计算机的软件知识和做项目提供了经验。大一尽管我边学软件工程，基础的编程还是弄得很扎实，我记得那时每个星期，都得花20元买上机票。到大二上的一段时间里，可能是对软件工程有一些理解，就不太注意基础的学习，为此我付出了一些代价，尤其是在学Java,由于java很贴近软件工程，感觉很好学，也易理解，所以没有花太多的时间在基础编程上，而是把精力放到与软件工程中来。后来在课程设计的编程就差点栽跟头了。就是因为在软件工程方面说得头头是道，而基本的编程程序支持太少。幸好在老师的监督和学长的指导下，及时调整才使自己向着一个比较良性的方向发展。
现在看来，虽然有些东西学的时间不对，但是自要用心学了，就有好处。如果能把所学的东西相互结合起来，而不是孤立的学东西，那是再好不过了。我觉得软件工程和数据结构什么时候都可以学，哪怕你刚开始入大学，前提是要用心学，但不能忽视了解基本的东西，以基础知识的学习为主；如果能从基础的东西中找到他们的影子，那你无论是自学这两门课，还是学基础课都是成功的。
最后我想说的是不管你有什么想法，或者想有更高的起点，一定要注意有一个牢固的基础，这个基础是计算机体系的基础知识，而不是大学的所有基础知识。当然如果都学好了，那更好。
在计算机的学习过程中，可以选择工具，但不要相信工具，可以学习高级的技术，但一定要弄清它的基础支持和思想，不要被一些表面的套话所蒙蔽，要打牢基础的知识和编程技能，更要学会融会贯通。
下面是那篇文章：来源于：http://51cmm.csai.cn/OO/NO000037.htm
一道笔试题与UML思想
作者：温昱（来源：松耦合空间）时间：2005年03月18日
一句软件工程界的名言，让我想起了一个和一道笔试题有关的故事。希望更多的人了解 UML 背后的思想比它的语法更重要，是笔者写作本文的一点小愿望。
一、从一句软件工程名言说起
对很多事情的处理上，东西方都大相径庭。究其根底，往往是东西方文化的差异使然。 “ 有工具的傻子还是傻子！（ A Fool with a Tool is Still a Fool! ） ” 这句在软件工程界颇为有名的话，就体现了西方人说话不大客气的特点。作为中国人，你可能不大喜欢这句话的表达方式，但其内容的正确性是不容置疑的 —— 它强调了工具背后的思想才是最重要的。
UML 作为 OMG 组织认可的一种标准化的可视化建模语言，近年来在国内外软件界非常盛行 —— 相关的书籍不可谓不多，学习和使用 UML 的人不可谓不众。但是，笔者发现不少人犯了买椟还珠的毛病 —— 他们忘记了 UML 只是我们表达建模思想的工具，其背后的思想才是最重要的。
二、一道笔试题的故事
这道笔试题是这样的：
写出下列程序的运行结果：
public class Test {
public static void main(String[] args) {
Child child = new Child();
}
}
class Parent {
Parent() {
System.out.println("to construct Parent.");
}
}
class Child extends Parent {
Child() {
System.out.println("to construct Child.");
}
Delegatee delegatee = new Delegatee();
}
class Delegatee {
Delegatee() {
System.out.println("to construct Delegatee.");
}
}
这道题很简单，就是考构造函数的执行顺序，输出结果如下：
to construct Parent.
to construct Delegatee.
to construct Child.
然而，应试者没有写出程序运行结果，倒是画了一张类图出来：
我问他：“你画的类图很好，用 UML 几年了？”
他说：“ 2 年多了。”
我说：“为什么不写程序运行结果呢？太简单了吗？”
他嘿嘿一笑，说：“这道题考的是构造函数的执行，我记不大清了。”
我说：“构造一个类时，它的父类和成员变量所属类的构造函数都会被自动执行，具体顺序是先 Parent 后 Delegatee 最后 Child ，是吧？”
他说：“对对对。不过，我不喜欢这些细节性的东西，还是图形化的类图更能表达程序的思想。”
我说：“是呀，那么请你谈谈这个简单的类图中的思想好吗？”
他无言。
三、 UML 背后的思想
真是可惜，我本以为他会说出上面类图中的依赖思想呢。 UML 图里真的充满了思想，哪怕是上面那个如此简单的类图！
1、 继承的箭头为何指向父类
相信至今还有人会画出类似下面的类图，小小的一个错误却叫人不禁扼腕！其实，大师们把继承的箭头方向规定为指向父类，是有深刻的设计思想的——它代表了依赖的方向！
举个著名的面向对象原则——依赖倒置原则——的例子吧。依赖倒置原则（ Dependency-Inversion Principle ）规定：抽象不应依赖于细节，细节应该依赖于抽象。本原则几乎就是软件设计的正本清源之道。因为人解决问题的思考过程是先抽象后具体，从笼统到细节的，所以我们先生产出的势必是抽象程度比较高的实体，而后才是更加细节化的实体。于是，“细节依赖于抽象”就意味着后来的依赖于先前的，这是自然而然的重用之道。而且，抽象的实体代表着笼而统之的认识，人们总是比较容易正确认识它们，而且它们本身也是不易变的，依赖于它们是安全的。依赖倒置原则适应了人类认识过程的规律，是面向对象设计的标志所在。
下图是著名的观察者模式的一个变体，我们研究一下这个例子中的继承关系。 Braodcaster 和 Listener 是 Framework 层的两个类，负责完成我们在开发的前期就抽象出来的“订阅－通知”机制。而 ConcreteBroadcaster 和 ConcreteListener 是使用“订阅－通知”机制的类，是通过继承实现的。显而易见，依赖倒置原则规定的“细节依赖于抽象”，在这里表现为“继承的箭头从子类指向父类”。
2 、回到笔试题
其实，构造函数的执行顺序，何尝不是唯“依赖关系”马首是瞻呢？具体而言，就是“被依赖的先构造，依赖于人的后构造”。唯一可能的猫腻是：“跨层依赖”优先于“同层依赖”构造，如下图所示。
3、 买椟还珠
春秋时代，楚国有一个商人，专门卖珠宝的，有一次他到齐国去兜售珠宝，为了生意好，珠宝畅销起见，特地用名贵的木料，造成许多小盒子，把盒子雕刻装饰得非常精致美观，使盒子会发出一种香味，然后把珠宝装在盒子里面。有一个郑国人，看见装宝珠的盒子既精致又美观，问明了价钱后，就买了一个，打开盒子，把里面的宝物拿出来，退还给珠宝商。
呜呼，买椟还珠的故事在我们身边重演，可惜呀！
