假设方法M1和M2具有强烈相关的责任
第一个例子：
如果
•M1和M2在班级A中定义（因此班级A具有高度凝聚力）
•班级B使用A.M1，班级C使用A.M2
然后
•A与B和C类
•更改M1的签名只需要在B进行更改，但不能在C中进行更改
第二个例子：
如果
•M1在课程A1中定义（因此B与A1相结合）
•M2定义为课程A2（因此C与A2相结合）
然后
•更改M1的签名只需要在B进行更改，但不能在C中进行更改
a）据我所知，上一个例子中的类与第一个例子中的类不再耦合！或者我错过了什么？
b）据我所知，第一个例子中的类比第二个例子中的类更松散耦合，仅用于：
我们假设更改M1的签名也需要我们更改M2的签名，但我不经常看到这种情况发生？！
或者如果M1和M2对相同类型T1的数据进行操作，则将T1替换为T2将需要同时更改M1和M2 ？！
或者如果我们认为由于M1和M2责任密切相关，那么改变M1通常需要M2的可能性要大得多还要更改（即使M1没有直接或间接调用M2）？！
或者如果我们认为由于M1和M2的责任密切相关，某些课程需要M1和{{1}的机会要大得多（因此在单个类中M2和M1会减少耦合）？！
c）在M2中定义M1和M2是否有任何其他原因（而不是在A和M1中定义A1 M2内）会减少耦合吗？
注意 - 我知道由于维护和可重用性更容易，我们应该拥有高度紧密的模块
谢谢
答案 0 :(得分：2)
是的。你缺少的是，如果ClassA具有凝聚力，更改M1将导致ClassB访问ClassA中的其他方法。它增加了维护，因为您不必修改ClassA本身的其他模块（方法和变量）。
当我们称一个类有凝聚力（比如ClassA）时，我们的意思是我们可以很容易地使用类的目的，而不必根据ClassA的要求创建我们的调用者类（ClassB）。因此，ClassB不依赖于ClassA，从而降低了凝聚力。
不要想到在方法方面考虑凝聚力。方法不称为衔接，类是。