本文是我和近来认识的高级程序员tony的谈话内容整理而成。Tony他对程序设计的认识足以使我无地自容。Tony是个十分低调的人，不为重用也没什么名气（我想他也不看重名气），设计好的程序是他最大的理想。
《浅论设计》
nyra(
[email protected]) & solo-tony (
[email protected])
1、引言
软件的产生过程，大概可分为计划，实现和维护三个部分。实现过程主要有四个工作：分析，设计，编码，测试。本文主要讨论设计工作的方法。
2、设计的前提
分析需要（需求分析）是设计的前提。它为设计工作提供了目标和基础，设计工作就是在分析产生
的目标和基础之前找到一条合理的路线。假如目标和基础都是明确的，那设计工作实际上就没有了任何
意义，好比你要找一本书，如果你知道是什么书（目标），又知道图书馆在哪里（基础），那么设计工作
就只变成了知识的组合（把有关于图书检索的知识组合起来），这时候设计工作就好比是中国的考试一样
无聊，Tony说：“何不写个应试程序呢？”自动化的CASE工具可以帮助我们完成这些设计。
设计工作的挑战在于分析不可能得出一个清晰明确的目标，甚至不能知道现在的基础是什么样的。在
为别人设计程序时（一些大客户），他们的要求通常三天一变，这种变化是计划所不能企及的，也是对分析
的否定，同时也对设计的挑战。另外，在很多情况下，我们，做为程序的实现人员都是无知的，我们对手中
的工具一知半解，对自己的水平过于自信，这些都很可能导致在分析的时候得出不正确的结果，不能知道现在
的基础是什么样的。我们必须认同分析中这种不确定性，不能指望分析的结论是完美无缺的。
3、设计的理念
3.1没有正确的设计理念
每一种设计方法或思想都试图证明它是正确的，这种尝试就像在证明两条平行线永远不相交一样。任何一种设计方法都是有效的，但都有其局限性，只在特定的情况下有效，也不一定比其它的都好。
关键是我们是否认同它，并把它当成公理来使用。
3.2面向对象是我们的公理
Tony和我达成了这种认同，这是我们谈话的基础也是核心内容。而这种认同基于以下的理由：
1）OO（Object Oriented)更接近人的思维方式。人思考问题时，概念是最基本的单位，这正是OO中对象所描述的。
2）OOD（Object Oriented Design)有非常好的支持。很热门的东西总是有很多的支持者，比如UML，C++等。这使得OOD很容易，容易做也容易实现（变成代码）
3）最后，也是最不成理由的是我们喜欢常用它。习惯也许是最关键的因素。
3.3面向对象的设计层次
汇编语言也可以用做实现OOD的编码工具。但是它位于OO的最低层，在为汇编语言所做的OOD中，连最基本的对象概念都要明确说明。OOD中由大到小，可分为三个层次：框架（framework)，模式(pattern)和成语(idiom).它们从不同的抽象层次对设计的方法做出了说明。
1）框架：框架是一种成熟的设计思路，它着眼于设计的内容，即设计的主体部分。框架为设计指明方向。典型的框架有win32下的MFC, OWL, OpenClass等。它们通常很大，无所不包，使用框架可以明确设计的主体结构。虽然大多数框架都有实用性的类，比如MFC中CArchive类。但它们只能做为框架描述的工具，而不能做为应用的直接内容；它们可以做为应用的实现基础却不能直接使用。
2) 模式：模式是一系列类的组合方法，它着眼于概念的组织，即设计的枝节问题。它可以把框架的描述类有效的组合起来，产生类树（群）。典型的模式在Gof的书中有详细的描述。模式解决的是设计中如何走的问题，它可能解决走哪一条叉路的问题，也可能解决涉水还是搭桥的问题。它不能解决向什么方向走的问题（这由框架决定），不能解决走路还是坐车的问题（这由成语解决）。它是设计工作中比较常用的抽象层次，通常讨论的设计问题都在这一层次上。
3）成语：成语是语言相关的，它指某一种程序设计语言中实现某些功能的习惯方案。它可以大到如何实现类，小到循环变量是i还是conter.成语的掌握程序通常说明了设计师对语言的功力。好的设计师不应在面对“访问却不能属于”（C++中的friend，java中的内嵌）这样有点复杂的问题就束手无策
4、设计的过程
设计没有结束，也没有开始，广义来说整个软件开发过程都弥漫着设计的成份，计划或维护的任何想法都是设计的一部分或是影响设计的因素之一。反复设计和持续设计是必要的，也是不可避免的。设计应保证自己的可扩展性。设计的变化不应导致大量其它工作的无效.简单的说就是应尽量设计可复用的代码，减少专用代码的比例，但这一条规则却不只针对代码。
5、结语
成功的设计来自于实践，却不局限于实践。设计的思想（我们不说灵感，因为灵感通常认为是神秘而不可琢磨的）来自于生活的
各个方面，只有真的热爱并多方面的体验生活才有多样的思想。
