软件架构坏味道.pptxVIP

20.1引言20.2典型的代码坏味道20.3典型的设计坏味道20.4本章小结 软件架构坏味道 引言（1） 坏味道可能存在于程序的代码中，也可能存在于软件设计中，还可能存在于系统的模型、文档和数据中。 本章中主要讨论代码坏味道（code smell）和架构坏味道（architectural smell） 引言（2）代码坏味道（code smell）如果程序中的某一段代码是不稳定或者有一些潜在问题的，那么该段代码往往会包含一些明显的不太好的痕迹。我们称这些痕迹为“代码坏味或者代码异味”。 20.1引言（3）架构坏味道（architectural bad smell）Lippert和Roock，2007年提出他们认为架构坏味道定义与代码坏味道（code bad smell）类似的坏味道，只是架构坏味道在系统粒度下出现的层次要高于代码坏味道。 20.1引言（4）架构坏味道定义架构坏味道是一种通常使用的、可以对系统生命周期特性产生消极影响的架构设计。它可能是由于在不适当的环境下应用了一个不合适的解决方案或者在错误的粒度层次下应用了某个设计抽象等产生的，会对系统的可理解性、可测试性、可扩展性以及可重用性等产生负面影响。 20.1引言（5）架构坏味道定义的扩展Joshua等人对架构味道进行了进一步的定义，并从除生命周期特性之外的三方面对该定义进行了扩展：（1）明确定义架构坏味道是一个设计实例，它是独立于工程设计过程而存在的。（2）不具体区分架构坏味道究竟是设计计划的一部分还是设计实现的一部分。（3）可以依据标准架构模块，例如组件、连接件、接口等，通过对架构坏味道种类的明确定义简化架构坏味道的检测过程。 20.2典型的代码坏味道（1） 代码坏味道的类型很多，这里从三个角度把面向对象程序中可能出现的代码坏味道分成应用级的坏味道、类级的坏味道和方法级的坏味道三种类型。 20.2典型的代码坏味道（2）20.2.1应用级的坏味道（1）重复代码（Duplicated code）：是指在一个以上的地方出现了重复的代码片段。重复的代码结构使程序变得冗长，需要重构。例如：一个父类有两个子类，这两个子类中存在相同的表达式。解决方案?: 对两个子类使用?提炼方法， 然后使用?上移方法（Pull Up Method）将将提炼出来的代码定义到父类中去。 20.2典型的代码坏味道（2）20.2.1应用级的坏味道（2）人为复杂性（Contrived complexity）：在进行简单设计就充分的情况下，强制使用了过于复杂的设计模式。（3）散弹式修改（Shotgun surgery）：如果每遇到某种变化，你都必须在许多不同的类中做出许多小修改。如果需要修改的代码散布四处，你不但很难找到它们，也很容易忘记某处重要的修改。这种情况应该使用移动方法（Move Method）和移动域（Move Field）的方式?把所需要修改的代码放进同一个类中。 ? 20.2典型的代码坏味道（3）20.2.2类级的坏味道（1）过大的类（Large class）：如果想利用单个类做太多事，类中就会出现太多实例变量。可以使用extract class 将几个变量一起提炼至新类内。如果large class是个GUI类，可能需要把数据和行为移到一个独立的领域对象去。 20.2典型的代码坏味道（3）20.2.2类级的坏味道（2）依恋情结的类（Feature envy）： 即一个类的方法过多地使用了另一个的方法。某个类的函数对另一个类的兴趣高过对自己所处的类，通常的焦点就是数据，某个函数为了计算某个值，从另一个对象那儿调用几乎半打的取值函数。这时应该运用?Move Method?把它移到自己该去的地方。 20.2典型的代码坏味道（3）20.2.2类级的坏味道（3）过度亲密类（Inappropriate intimacy）：一个类存在与另一个类的实现细节依赖。 例如：两个类过于亲密，花费太多时间去探究彼此的private成分。可以采用move method和move field划清界限。可以通过把双向关联变成单项关联。 20.2典型的代码坏味道（4）20.2.2类级的坏味道（4）拒绝的馈赠（Refused request）：子类仅仅使用父类中的部分方法和属性，其他来自父类的馈赠成为了累赘。问题的原因是有些人仅仅是想重用超类中的部分代码而创建了子类。但实际上超类和子类完全不同。 解决方法：如果继承没有意义并且子类和父类之间确实没有共同点，可以消除继承。 20.2典型的代码坏味道（4）20.2.2类级的坏味道（5）冗赘类（Lazy class）：一个做的事情太少的类。冗赘类出现的主要原因：1）某个类原本对得起自己的身价，但重构使它身形缩水，不再做那么多工作； 2）或开发者事前规划了某些变化，