swing控制項是改善為了awt控制項而發展出來的輕量級gui控制項，採用的是composite設計模式，然而，由於沒有清楚的分隔元件（component）和容器（container）的邊界，就造成了swing的幾乎每個單獨的元件都是乙個容器，能夠新增其他容器或者元件，看似強大的功能實際上造成了大量的問題：
1.和人的直覺非常不一致：swing的gui上的各種元件如果新增的面板過多的話，就造成各個元件的層次很深，處理類似focus管理這樣的問題就很麻煩，座標的轉換也很複雜，由於父子關係過多，您不看**只看gui，憑直覺難以區分元件的父子關係。
2.使用上的困擾：swing元件本身由於不能分清是元件還是容器，很多容器方法比如setenabled就沒有效果，需要寫**遍歷所有子元件，呼叫所有的子元件相同的方法，而類似設定透明的方法也有這個問題，如果設定某個容器透明，也需要設定所有的子元件的透明屬性，元件和容器的很多方法沒有很好的定義，這對了解swing結構的人不是問題，但是對於熟悉別的ｇｕｉ類庫的人就產生了很大的困惑，因為不少容器上的方法呼叫後是沒有效果的。
3.布局上的困難：使用swing開發介面的程式設計師會發現，即使swing提供了這麼多布局管理器，然而您想通過這些布局管理器做出很專業的介面卻非常難，因為布局管理器非常依賴父容器和子元件的各種狀態，儘管swing最新的版本提供了類似元件和容器間隔的方法，然而還沒有被大部分布局管理器採用，其實並不是布局管理器不夠強大的問題，事實上，很多專業的介面需要從元件級別做出良好的定義，例如getpreferredsize，getminimumsize，getmaximumsize方法，這些方法的不確定性很強，布局管理器不能過度依賴這些方法；另外，不少swing元件會根據容器的大小進行繪製，這也造成了很多不確定性，很多人喜歡使用nulllayout，可能就是這個原因，客戶需要的是乙個穩定的，可預知的介面，如果使用了布局管理器，會發現介面在不同的系統下展示的不同。
而對比不少gui類庫，您會發現他們的定義更為嚴格，比方j**ame lcdui類庫，元件和容器是嚴格分開的，元件的新增是嚴格限制的，布局也是定義的非常嚴格的，沒有布局管理器，類似滾動條這些支援都在底層進行了隱藏，真正減少了gui開發者的負擔。
總得來說，對composite設計模式應該慎用，如果一定要用，一定要良好的定義元件（component）和容器（container）的邊界，不然很多功能會陷入沒有意義的父子遍歷例程，增加了複雜性，卻沒有帶來很多好處。
mvc模式再Swing中的應用
將乙個swing得頁面作為view,將資料處理成model,再使用乙個controller控制他們得邏輯。進一步深入得話，可以引入監聽方法，將每乙個view,作為乙個listener,實現乙個listener介面,再controller中加入listener event得註冊方法，再detector...
Spring框架中的設計模式（三）
這篇文章的第乙個設計模式是原型。可以通過官方文件查詢有關spring作用域中的bean作用域的文章中介紹了類似的概念 prototype 原型設計模式與有用相同名稱的 prototype 作用域有點相似。此設計模式允許通過複製已存在的物件來建立乙個物件的例項。副本應該是真正的副本。這意味著新物件的所...
框架模式和設計模式
很多程式設計師往往把框架模式和設計模式混淆，認為mvc是一種設計模式。實際上，他們是完全不同的概念。框架模式和設計模式這兩個概念總容易混淆。其實它們之間是有區別的。框架通常是 重用，而設計模式是設計重用。在軟體成產中有三種級別的重用 內部重用 在同一應用中能公共使用的抽象塊 重用 將通用模組組合成庫...