软件设计之道1

,软件设计专用教程,中程在线(北京)科技有限公司,内部教程 注意保密,什么是优秀的设计,抗拒变化是无用的,他们不知道自己需要什么，因此也无法提出要求 他们知道自己需要什么，但不知道如何说明它 他们能够说明，但我们误解了他们 我们理解了，但漏掉了隐含的意义、优先级或细节 所有这一切都没问题，但市场总会变化,软件需求变更法则,软件不断变更法则:真实世界中使用的程序必须进行变更,否则它在环境中的作用就会越来越小.,敏捷思想最大的贡献-1,对软件需求变化的态度 传统工程学里有一个基本假设是，需要对未来有很详 细的计划和预测，有清晰的进度和流程。但其实软件 开发非常不同，它包含很多艺术的成分，人的创造力 至关重要，而且软件的需求非常易变。而敏捷对预测 未来的方式是全新的，强调通过提高团队的能力、设 计的弹性和流程的灵活性来适应变化。这种思路对软 件开发也是很大的冲击。,案例分析-1,需求描述 客户名称:影片租赁连锁企业 统名称:影片租赁管理系统 需求描述: 1:完成影片连锁企业租赁管理系统, 可以计算每一位客户的消费金额和影 片的详细信息,金额根据影片的类型和租赁的日期来进行计算. 2:客户把影片分成3类进行管理 A:最新电影 B:普通电影 C:儿童影片. 注 意新片在拿到后的3个月之后,把新片修改为,普通电影或者儿童电影. 这些 类型可以转换. 3:费用计算规则如下 a:是普通电影,如果租期小于2天,费用为2元钱.如果租期大于两天,费用是 租期减去2,每天1.5元 b:如果是欧美新片电影,费用为每天3元 c:是儿童电影,如果租期小于3天,费用为1.5元钱.如果租期大于三天,费用 是租期减去3,每天1.5元 4:每次客户租赁电影可以为客户积累积分,规则是每次累计增加1分. 如果 是新片,并且租期大于1天,再增加一分 5:暂且不要考虑系统界面问题和系统的存储问题,案例分析-2,认证案例分析,总结,增加一个功能特性的成本并不单单是为这些功能编码所花费时间的成本，还应该包括特性扩展的障碍成本。,什么是好的设计,一个好的系统设计应该有如下的性质：可扩展性、灵活性、可插入性。 好的设计的目标 可扩展性(Extensibility): 新的功能可以很容易地加入到系统之中,这就是可扩展性. 灵活性(Flexiblity) ：可以容许代码修改平稳,而不会波及到很多其他的模块.这就是灵活性 可插入性(Pluggability) ：可以很容易地将一个类抽出去,同时将另一个有同样接口的类加入进来.这就是可插入性.,开放封闭原则（OCP）,软件组成实体（类，模块，函数，等等）应该是可扩展的，但是不可修改的。 即软件实体可以通过增加新代码实现扩展,但是不能修改已有的代码 任何系统在其生命周期中都会发生变化。如果我们希望开发出的系统不会在第一版本后就被抛弃，那么我们就必须牢牢记住这一点。,优秀设计,发现变化/封装变化 隔离变化 动态绑定 解耦具体依赖,适应变化,好的程序设计所面临的最主要的挑战之一就是适应变化.,设计原则1：发现变化，封装变化,找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起. 实现:把会变化的部分取出并封装起来,以便以后可以轻易地改动和扩充此部分,而不影响不需要变化的其他部分.,抽象稳定接口设计,设计原则2：抽象稳定接口，针对接口,抽象接口:创建出固定却能描述一组任意个可能行为的抽象体,这个抽象就像抽象基类或者接口,任意个可能的行为就是可能的派生类. 针对接口(抽象)设计:由于模块子间依赖一个固定的抽象,所以它对于更改可以是关闭的.,某银行系统,设计原则3：分离变化维度，单一职责原则,单一原则:就一个类而言,应该仅有一个引起它变化的原因. 职责定义为 “变化的原因(a reason for change)”,如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.,静态绑定 与 动态绑定,代码结构在编译时刻就被确定下来了，比如它由继承关系固定的类组成，或者硬编码实现等。 而程序的运行时刻结构是由快速变化的对象实现。编译时两个结构是彼此独立的。,蜡笔（粗细的变化和颜色的变化，静态绑定）,画笔（粗细的变化和颜色的变化，分离，动态绑定）,设计原则4：尽量动态绑定，组合/聚合复用原则,尽量的使用合成和聚合，而不是继承关系达到复用的目的。 该原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分：新的对象通过向这些对象的委派达到复用已有功能的目的。,多态与继承,继承是多态的基础,多态是继承的目的! N×M PK N+M,对象的创建,传统语言中的对象创建 每个对象都有一个构造函数，它负责对象的创建，（有些语言还有析构函数，负责对象的释放，然而Java使用垃圾收集器，负责对象的回收） 使用传统的对象的创建 Customer object obj =newCustomer（）；,为什么需要创建型模式 ,创建对象使用hardcode方式 Class obje=new Class(); 使用这种硬编码方式，不遵守OCP原则，一旦修改或者增加实现类，就修改已存在地代码，可维护性差 系统需要针对接口编程而不是对实现编程 客户端关心是接口，而不是具体的实现，因此不应决定创建那个具体的实现类,设计原则5：创建与使用分离,设计原则:对象要么构造对象,要么使用对象,而不应该兼而有之.如果遵守这一约束,加强内聚和降低耦合 如果你吃了一只鸡蛋觉得味道不错，难道一定要见到那只母鸡,解耦具体依赖,4种方式 配置文件与反射技术 表驱动法 惯例优于配置 依赖注入,方案1-配置文件与反射技术,将反射技术与配置文件结合,在具体对象拥有共同抽象的前提下,通过配置文件获得具体的对象类型,然后利用反射创建相应对象.,必须知道的设计法则,找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码交织在一起. 抽象稳定接口（抽象类），针对接口编程,而不是针对实现编程 分离变化维度，单一职责原则 动态绑定还是静态绑定，多用组合,少用继承 创建与使用分离，创建有变化也要封装,面向对象详细设计的设计原则,软件系统开始坏死的症状, 一个软件系统开始坏死时表现的症状有:, 硬化Rigidity系统变得越来越难以变更,修复或增添新,功能的代价高昂;, 脆弱Fragility对系统的任何哪怕是微小的变更都可能 造成四处(甚至是与变更处没有逻辑上的关联之处J崩溃; 绑死Immobility抽取系统的任何部分用来复用都非常,困难;, 胶着Viscosity以与原有设计保持一致的方式来对实 施变更已经非常困难,诱使开发人员绕过它选择容易但有 害的途径,其结果却使系统死的更快,详细设计的设计目标,质量属性对详细设计的影响,合适性：即体系结构是否适合于软件的“功,能性需求”和“非功能性需求”, 设计师可以充分发挥主观能动性，根据需求的特征，通过推,理和归纳的方法设计出合适的体系结构。经验不丰富的设计 师往往把注意力集中在“功能性需求”而疏忽了“非功能性需求” ，殊不知后者恰恰是最能体现设计水平的地方。, 高水平的设计师高就高在“设计出恰好满足客户需求的软件，,并且使开发方和客户方获取最大的利益，而不是不惜代价设 计出最先进的软件。（以设计住宅为例）, 对于软件系统而言，能够满足需求的设计方案可能有很多种,，究竟该选哪一种？此时商业目标是决策依据，即选择能够 为开发方和客户方带来最大利益的那个设计方案。大部分软 件开发人员天生有使用新技术的倾向，而这种倾向对开发商 业产品而言可能是不利的，切记切记。,结构稳定性, 当前中国有几句流行的至理名言：“稳定压倒一切”、“发展,是硬道理”。发展的前提条件是稳定，社会如此，开发软件 产品也是如此。, 体系结构一旦设计完成，应当在一定的时间内保持稳定不,变，只有这样才能使后续工作顺利开展。如果体系结构经 常变动，那么建筑在体系结构之上的用户界面、数据库、 模块、数据结构等等也跟着经常变动，用“树倒猢狲散”来 比喻很恰当，这将导致项目发生混乱。,高水平的设计师应当能够分析需求文档，判断出哪些需 求是稳定不变的，哪些需求是可能变动的。于是根据那些 稳定不变的需求设计体系结构，而根据那些可变的需求设 计软件的“可扩展性”,可扩展性,可扩展性是指软件扩展新功能的容易程度。可扩展性越好，表示软件适 应“变化”的能力越强。可扩展性越来越重要，这是由现代软件的商业模式 决定的：,社会的商业越发达，需求变化就越快。,现代软件产品通常采用“增量开发模式”，开发商不断地推出软件产品的新版本 从而不断地获取增值利润。,稳定性和可扩展性之间存在辨证的关系：如果系统不可扩展的话，那么就没有 发展前途，所以不能只关心稳定性而忽视可扩展性；而软件系统“可扩展”的前 提条件是“保持结构稳定”，否则软件难以按计划开发出来稳定性是使系统能够 持续发展的基础。所以稳定性和可扩展性都是体系结构设计的要素。,如果每次变化都导致体系结构发生大的变动，那简直就是“伤筋动骨”，这样的 体系结构无疑是败笔之作。（例如房屋装修）,可复用性,复用就是指“重复利用已经存在的东西”。被复用的对象可以是有形 的物体，也可以是无形的知识财富。复用不是人类懒惰的表现而是 智慧的表现。因为人类总是在继承了前人的成果，不断加以利用、 改进或创新后才会进步。,复用的有利于提高产品的质量、提高生产率和降低成本。由经验可 知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内 容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有 高质量），而大量成熟的工作可以通过复用来快速实现（即具有高 生产率）。勤劳并且聪明的人们应该把大部分的时间用在小比例的 创新工作上，而把小部分的时间用在大比例的成熟工作中，这样才 能把工作做得又快又好。,面向对象的设计原则一开放-关闭原则,动机,一个设计良好的应用程序应该充分考虑到开发和维护阶段需求的频繁变化，通常情况下，添加一个新的功能需要做出很多修改，我们应该使对已有代码的修改最小化，因为他们已经经过了测试。对现有代码做出修改将会以一种不可预料的方式影响它们的已有功能。,开-闭原则-1,一个软件实体应该对扩展开发，对修改关闭。开闭原则是说我们应该努力设计不需要修改的模块。在扩展系统的行为时，我们只需要添加新的代码，而不需要修改已有的代码。一般可以通过添加新的子类和重写父类的方法来实现。,开-闭原则-2,满足开闭原则的模块符合下面两个标准： 对扩展开放- 模块的行为可以被扩展从而满足新的需求。 对修改关闭- 不允许修改模块的源代码。（或者尽量使修改最小化） 怎样实现开闭原则 抽象、接口、多态、继承 要想使一个软件系统的所有模块都满足开闭原则是不太现实的，不过我们应该努力使大部分模块满足开闭原则。开闭原则是面向对象设计的核心，满足该原则可以达到最大限度的复用和可维护性。,实例,代码-2,代码-3,代码-4,总结,像许多其他原则一样，开闭原则只是面向对象设计的一个原则，实现一个灵活的设计需要额外的时间和努力，引入新的抽象层会增加代码的复杂性。因此，该原则适用于那些需求会经常发生变化的系统。有许多设计模式可以帮助我们扩展功能而不需要修改代码。例如，装饰模式等。,面向对象的设计原则一单一原则,动机,在本文中职责是指引起变化的原因。该原则表明，如果你有多个原因去改变一个类，那么应该把这些引起变化的原因分离开，把这个类分成多个类，每个类只负责处理一种改变。当你做出某种改变时，只需要修改负责处理该改变的类。当我们去改变一个具有多个职责的类时可能会影响该类的其他功能。,单一职责原则,一个类应该只受一种变化的影响。 单一职责原则简单而直观，但是在实际实现中可能是很困难的。,实例,假设我们需要一个对象保存email 信息，在下面的例子中我们