耦合性 Coupling 一群类别的耦合得愈紧密，愈难了解整个系统，也愈难进行维护。如果类别之间有相依性 ，那麽修改一个类别，也得修改另一个类别，才能满足需求。但是，寻找所有需要修改的 地方是非常耗时的工作，也容易发生错误。而且，在另一个系统中重复使用既有的类别， 必须将其耦合的类别也涵盖进来，否则该类别无法运作。 减少类别的耦合性可以提升系统的维护性，以下由强到弱依序列出耦合性的种类 1. Content coupling 说明：一个类别直接修改另一个类别的内部资料。 建议：永远避免此种耦合性。 解决：利用封装来保护类别的内部资料。 2. Common coupling 说明：一个类别含有全域变数，开放给所有类别存取。 建议：最大地避免此种耦合性。 解决：利用封装来保护类别的内部资料；设置常数来防止修改；套用 Singleton Pattern 来封装物件的全域存取；只在系统相关的类别留下全域变数。 3. Control coupling 说明：藉由一个控制变数来决定另一个类别的行为。 建议：尽量避免此种耦合性。 解决：利用多型来决定合适的行为；建立表格来记录控制变数与其对应之行为。 4. Stamp coupling 说明：你所定义的类别出现在另一个类别的方法之参数串列中。 建议：有些情况下，此耦合是必要的；但是有些情况下，最好排除此种耦合性。 解决：使用介面来取代参数型态；使用基本变数（整数、浮点数、字串）来取代参数。 5. Data coupling 说明：方法中的参数是一连串的基本变数（整数、浮点数、字串） 建议：虽然几乎不用避免此耦合性，但是一个方法含有愈多的参数，则耦合性愈强。 解决：减少不必要的参数；在 stamp coupling 和 data coupling 之间取舍，三个或四 个参数以上不如一个介面来的简单。 6. Routine call coupling 说明：一个类别呼叫另一个介面所定义的方法 建议：不需要特别避免此耦合性，但是如果某一系列的方法经常伴随出现，则耦合性愈强 。 解决：创造一个方法来封装经常伴随出现的方法串列。 7. Type use coupling 说明：一个类别使用另一个类别 建议：虽然修改成员变数与方法的名称，需要一起修改使用者呼叫的地方所使用的名称， 但是不需要特别避免此耦合性。 解决：使用介面而非类别。 8. Inclusion/import coupling 说明：在 Java 中 import 一个 package 或在 C++ 中 include 其他模组。 建议：虽然被 import 或 include 的类别修改之後，呼叫该类别的地方可能需要跟着修 改，避免发生新旧版本的冲突，但是不需要特别避免此耦合性。 解决：不要 import 或 include 不需要的模组；尽量只 import 或 include 标准函式库 。 9. External coupling 说明：一个类别依存於作业系统、共享函式库、硬体设备。 建议：尽量减少含有依存性的程式码 解决：套用 Façade design pattern 来提供外部设备的使用介面。 每种耦合性都举例的话，那会是长篇大论，所以我只简单介绍耦合性，算是给个设计的指 引。我发现 Wikipedia 所述之耦合顺序与我所参考的书物有些不同，何者比较有道理就 由阅读者自己判断吧。 参考书物： Object-Oriented Software Engineering 2/e - Practical Software Development using UML and Java Wikipedia: http://en.wikipedia.org/wiki/Coupling_(computer_science) --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.116.247.13