漫谈程序代码的相依性.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 漫谈程序代码的相依性 Qing qing@cs.nthu.edu.tw (Email/MSN) 2008/10/16 程序代码间的相依性 在程序设计上，我们通常都会尽量降低程序代码之间的相依性 程序代码间的高相依性会带来许多负面的效应 其中最令程序设计者头痛的，莫过于程序代码变动所造成的冲击 当两个程序代码元素之间存在相依性时，当被依赖的那一个元素有了变化时，就有机会造成另一个元素也受到波及，因而必须跟着一同变化 当你修改某个被许多其他的程序代码元素高度依赖的程序代码元素时，可能会影响到的层面将会十分广泛 不同粒度之程序代码元素间的相依性 所谓的程序代码元素之间的相依性，其实还是可以在不同的粒度（granularity）上去检视，例如 链接库和链接库之间 package和package之间 类别和类别之间 函式和函式之间 无论放在那一种粒度的层级上看，高相依性都不会是一件好事 大名鼎鼎的Jakarta ApacheProject，其中的许多链接库都和同一项目下的许多程序库存在着相依性 采用其中一者，也得同时引入其他，造成了高度耦合的情况 程序员最关心的相依性 一般程序设计者来说，多半比较关心package间的相依性以及类别之间的相依性 类别之间的相依性更是许多设计技巧与方法关注的重心 本讲题将以类别之间的相依性为主 何谓类别间存在相依性？ 当类别A相依于类别B时，意指当我们改变B的接口时，我们可能得修改A 所谓的相依性，其实是对另一类别接口的依赖 下述的情况都是A相依于B的例子， A存取B的值 A呼叫B的函式 A外貌式（signature）中的回传型别或自变量列表中含有B UML中的相依性关系 UML中类别间可能存在相依性关系（dependency relationship） 我们在评估两个类别之间是否存在相依性时，其中的「相依性」其涵盖范围就不仅仅局限于UML中所提及相依性关系，例如 相依性可能源自于继承关系 你的设计是否考虑相依性？ 你在进行设计的时候，是否曾经将设计的相依性高低与否纳入考虑呢？ 你是否会在设计时，试着降低类别与类别之间的相依性呢？ 利用工具分析相依性 有许多工具可以协助你分析你的系统中各类别之间的相依性 我所使用的一个工具能产生左方的相依图（dependency graph） 相依图 所谓的相依图，即将你系统中存在相依性的类别之间以带有箭号的线条相连接 相依性是单向关系 类别A相依于类别B（此时箭号指向B），不意谓着类别B也同样相依着类別A 例：DBFacade依赖SQLManager、SQLExecutor及QueryResult 从相依图观察设计上的问题 从相依图中可以观察出现有程序代码在设计上的一些问题 当某个类别被许许多多的箭头所指向时，意谓着它是被高度依赖的类别－当这个类别有所变动时，可能会影响到的类别数量就会很多 存在一个高度依赖其他类别的类别，同样也不是一件好事－这个类别有可能会被频繁的更动，因为只要任一个它所依赖的类别有了变化，它都有机会被波及 循环相依（circulardependency） 使用相依图观察设计缺失的弱点 相依图分析工具多半属于静态分析的形式 仅能分析静态的程序代码，而无法捕捉到系统于执行期的行为－利用relfection机制的程序代码，便难以分析 大量利用reflection的系统仍然是少数 懂得运用reflection机制的程序员，也多半会留意相依性的议题，所以并不构成此类工具的重大缺陷 设计时将相依性时时牢记于心 在设计类别以及类别所具备的接口时，必须时时刻刻把类别间的相依性放在心里 让你自己总是思考如何降低自己设计中类别间的相依性，进而持续的改善自己的设计 许多导因自相依性的设计问题，多半都是由于设计者不在意、或是不知道应该要留意设计中类别的相依性而引起的 Program to interface, not an implementation GoF的DesignPatterns一书中提到设计时的一个重要原则：「针对接口来撰写程序，而不要针对实作（Program to interface, not animplementation）」 从相依性的角度来理解这个原则，原因便不言可喻 倘若你的客户端程序相依五个实作的类别，那么它在相依图上，就有着五条对外的连结 如果这五个实作的类别有着共通的接口，那么你就有机会让你的客户端程序仅相依于该接口，因此大大的降低了相依性的程度 （只相依于一个接口） 即便后端的实作类别有所变动，共通的接口也能扮演着缓冲的角色，有机会吸收掉实作类别造成的冲击，也就不致于影响到客户端程序 相依距离 在相依图上两类别间若存在一