我得到了这组代码，需要提出改进代码的内聚性和类的耦合性的方法。但我认为这些类是很好的去耦合，因为它们看起来像是在利用事件。就内聚性而言，所有的init（）调用都放在一起，对我来说一切都很好
public class A
{
private C t;
private B g;
public static void main(String args[]) {
// Creates t and g.
t = new C();
t.init();
g = new B();
g.init();
g.start(this);
}
pubic void update (Event e)
{
// Performs updating of t based on event
}
}
public class C
{
public C() { ... }
public void init() { ... }
}
public class B
{
public B() { ... }
public void init() { ... }
public void start(A s) {
e = getNextEvent();
while (e. type != Quit)
if (e.type == updateB)
update(e) ;
else
s.update(e) ;
e = getNextEvent();
}
public void update(Event e) { ... }
}
}
还有什么方法可以提高类的内聚性和耦合性吗？我觉得还可以，但我想我遗漏了一些东西。
谢谢你对此提出的任何建议。
开始编写单元测试（做TDD更好）。这种耦合（以及在较小程度上的内聚性或缺乏内聚性）将立即变得明显。
例如，类B的start方法有一个类型为a的参数。在您的示例中，您可以实例化a，但如果a有其他依赖项呢？也许所有的启动需求都是A实现的接口（带有更新方法）。
getNextEvent做什么？如果它使用其他依赖项，那么在测试中获得B可能会很困难。
测试可以帮助验证您的设计。
一个建议是将事件处理逻辑与控制器逻辑（A类）解耦。
所以你会有4种类型的类：
- 用于运行"服务器"（A）的主类
- 侦听事件的线程（B）
- 将被更新的模型层（C）
- 一个事件处理程序类，它将支持对事件（D）的某些操作
它可能看起来像这样：
public class Main {
private Model m;
private EventListener listener;
... main() {
m = new Model();
listener = new EventListener();
EventHandler eventHandler = new MyEventHandler();
// set the event handler
listener.setEventHandler(eventHandler);
listener.start(m);
}
public class Model {
// nothing to see here
}
public class EventListener() {
private EventHandler handler = new DefaultEventHandler();
public void start(final Model m) {
// startup
while (event.type != Event.Quit) {
// get event
handler.handleEvent(event, m);
}
// shutdown
}
public void setEventHandler(EventHandler eh) { this.handler = eh }
}
public class MyEventHandler implements EventHandler {
public void handleEvent(Event e, Model m) {
// update the model
}
}
请注意，在这个新设计中，更新模型的业务逻辑（在您的示例中为C）已经转移到了一个外部类，而不是"Runner"类。这有点干净，因为Main类不需要知道什么是事件以及如何处理它们。
另一个优点是使用它可以使用链式事件处理程序或多个串行事件处理程序轻松地对复杂的事件处理进行编码。实现异步事件处理也很简单，因为B只负责调用处理程序，不需要理解事件类型。这有时被称为发布/订阅，并保持侦听器（B）和处理程序（您的update（e）方法）松散耦合的
如果看不到更多的代码，就很难说代码的解耦程度。事件是解耦代码的一种方式，但也会使代码更难理解和调试。
在设计类时，高内聚性意味着许多方法可以相互重用，而低耦合性意味着只需要公开一些公共方法。
在设计包时，高内聚性意味着包中的许多类相互依赖，而低耦合性意味着只有少数是公共作用域，或者通过接口与其他类传递消息。
高内聚性、低耦合性的好处应该是更少的痛苦，尤其是在应对变化时。如果它不能减轻痛苦，就不要花太多时间优化它。我知道这听起来像是在说陈词滥调，但在衡量高内聚性、低耦合性是否"足够好"时，你应该记住自己的衡量标准，而不是依赖于那些不一定理解你试图解决的问题的人的意见。
如果最初的设计是在未来使用事件处理程序来合并另一个功能或类，正如您所说，它已经被使用过了，那么只需专注于实现的策略模式和类或接口的优化。