转：http://siyangxie.wordpress.com/2010/02/05/design%e9%97%ae%e9%a2%98%e7%9a%84%e5%ad%a6%e4%b9%a0%e6%80%bb%e7%bb%93/

Design问题的学习总结

Posted on 2010年02月5日 by siyangxie

1. 系统设计步骤：
首先是需求分析。这包括，理解系统是要做什么，有哪些用户，用户希望系统提供什么服务/功能。这些是最基本的，进一步的，可以分析一下系统的规模及相应对性能的要求，输入输出是什么(或者说怎么跟用户交互)。
其次就是分解系统为若干子系统，并且找系统中出涉及到的各个对象。在甄别对象的时候，需要牢记，对象要封装用一组共同的数据和特性。然后就是分析思考各个对象，对内应该封装哪些状态和性质，对外提供什么接口和行为。与此同时要考虑各个对象之间的关系和interaction，把每个对象拟人化。关系有composition, association, aggregation等等，在设计对象关系的时候，要多注意考虑code reuse和future extention. Interaction是麻烦的地方，因为一个interaction中，涉及到两个或者多个的对象，很难分清楚，到底谁是哪个对象提供的这个行为："file.print(printer) or printer.print(file)?” 怎么办？一个是从语义行为的常理上分析，谁应该提供这个行为，一个是从软件设计的原则出发，例如力求避免紧耦合而使用一个manager.print(file, printer)，我也觉得这个是很难说清楚的，只有靠多分析了。
接下来就是考虑有哪些可能变化的东西(现在或者未来)，尽量把会变化的部分分离出来加以封装，并且时刻考虑，如何使得design更flexible，如何在未来添加新的code或者feature而不需要改动现在的code。这个时候，可以开始回忆熟悉的设计模式，考察有哪些设计模式可以应用，常用到的如decorator, bridge, strategy, factory, singleton, state, observer等等。
现在把类的框架搭好后，开始考虑动态的关系，即sequence diagram。我个人感觉就是系统提供的服务流程的描述。这里一个困扰我很久的问题是，如何把人机交互的GUI部分，跟GUI背后的各个类的工作，分离开设计。我现在就只能先假设不考虑具体的系统是怎么通过人机交互来提供服务的。
接下来就是考虑实现。一个重要且经常遇到的问题是，怎么管理数据和信息，信息本身可以会涉及到一个或者多个对象类。普遍的，系统都会提供信息搜索查询的服务，那么是用数据库？还是普通的数据结构(数组，map等)？哪些信息应该交给对象自己保存而不是让manager来保存？例如，在停车场设计的题目中，需要保存下“某Customer的车子Car停在位子Space上”的信息，这时候也要考虑，是否应该在space obj中记录停车的客户信息，是否应该在customer object中记录车位的信息？这时，如果考虑到，customer的代码，可能会被用到别的application中，因此不应该在customer对象中保存车位的信息。
2. 设计原则:
基本的OOD概念：封装，抽象，继承，多态
OOD五大原则：OCP(open closed), LSP(substitution), ISP(interface segregation), DIP(dependency inversion), SRP(single responsibility)
GOF设计三大原则：Program to interface; Favor composition over inheritance; Encapsulate what varies;
总体的目标是：promote flexibility and weak coupling; easy to maintain, easy to extend;