改進內聚和類的耦合

我給了這組代碼，需要提出一些方法來改進代碼的內聚和耦合類。但是我認爲這些類很好地解耦，因爲它看起來好像在利用事件。就凝聚力而言，所有的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) { ... } 
    } 
}

是否仍有改善類凝聚力和耦合方式？它看起來對我很好，但我認爲我錯過了一些東西。

感謝您對此提出的任何建議。

來源

2011-06-16 Carven

A，B和C之間應該有什麼關係？你可以改變你的例子有意義的類嗎？這個''不能從靜態的上下文訪問，順便說一句。 – Atreys 2011-06-16 19:12:56

一個建議是將事件處理邏輯與控制器邏輯（A類）分離。

所以，你將有4種類別：

用於運行「服務器」主類（A）
線程監聽事件（B）
模型層，將被更新（C）
的事件處理程序類，這將支持對事件的一些操作（d）

它可能看起來LIK E本：

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）的商業邏輯已移動到外部類而不是在「飛人」類。由於Main類不需要知道事件是什麼以及如何處理它們，因此這樣更清潔一些。

另一個優點是使用這個，你可以使用鏈式事件處理程序或多個串行事件處理程序輕鬆地編寫複雜的事件處理代碼。實現異步事件處理也很簡單，因爲B只負責調用處理程序，不需要了解事件類型。這有時被稱爲Publish/Subscribe，並保持聽衆（B）和處理程序（您的更新（e）方法）鬆散耦合

來源

2011-06-17 03:44:55 Asaf

沒有看到更多的代碼，很難說你的代碼是如何分離的。事件是解耦代碼的一種方式，但也會使代碼更難以理解和調試。

設計類時，高內聚意味着許多的方法，再利用對方，低耦合意味着你只需要公開一些公共方法。

當設計軟件包，高內聚意味着許多在一個包中的類的依賴於彼此，並且低耦合意味着只有少數是通過接口公共範圍，或與其他類的信息。

高凝聚力的好處，低耦合應該是痛苦小，尤其是當它涉及到應對改變。如果它不能減輕疼痛，不要花太多時間優化它。我知道這聽起來像是我在這裏吹噓陳詞濫調，但在測量高凝聚力，低耦合度是否「足夠好」時，您應該記住自己的指標，而不是依賴那些不一定了解您正試圖解決的問題。

來源

2011-06-16 19:08:04

如果原來的設計是將在未來的另一功能或類別，使用事件處理程序，如你所說，它已被使用，那麼只專注於對戰略的實施模式和類或接口的優化。

來源

2011-06-17 03:03:23 Efox

開始編寫單元測試（更好的是，做TDD）。耦合（以及較小程度上的內聚或缺乏）將立即變得明顯。

例如，B類的啓動方法有A型的參數在你的榜樣，你可以只實例化，但如果有其他的依賴關係是什麼？也許所有的開始需求都是A實現的接口（使用更新方法）。

getNextEvent是做什麼的？如果它使用其他依賴關係，那麼在測試工具中獲取B可能會很困難。

測試可以幫助驗證您的設計。

來源

2011-06-17 03:24:41 TrueWill

改進內聚和類的耦合

回答

相關問題