本文是我和近来认识的高级程序员tony的谈话内容整理而成。Tony他对程序设计的认识足以使我无地自容。Tony是个十分低调的人,不为重用也没什么名气(我想他也不看重名气),设计好的程序是他最大的理想。 《浅论设计》 nyra(nyra@sohu.com) & solo-tony ( solotony@sohu.com) 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、结语 成功的设计来自于实践,却不局限于实践。设计的思想(我们不说灵感,因为灵感通常认为是神秘而不可琢磨的)来自于生活的 各个方面,只有真的热爱并多方面的体验生活才有多样的思想。 |