Java Swing GUI用戶操作處理

應如何管理監聽器等？我發現只有一個按鈕的例子等Java Swing GUI用戶操作處理

我能想到的下列選項：

每個額外的類 - 看起來不正確，特別是當項目可以動態創建
對於每個組類（如Form1中，窗口2，controlButtonsOnLeft，controButtonsOnRight，MAINMENU， userMenu的，...），其中我會檢查哪個按鈕/組件引起這樣（經由的getSource例如方法）
一些超級（大小）控制米勒，將接受所有用戶操作每個
新的匿名類，它將調用控制器的方法與指定細節（可能枚舉）

而另一個問題參數：我發現了很多的例子MVC，我想知道什麼更好（或常用）的應用程序。由1人開發（應用程序不會很大）？

A.查看器設置聽衆控制器（A1-3）

B.控制器調用觀看者的方法，它接受作爲聽者參數（方法addLoginSubmitListener，addControlBoldButtonListener等）

所有的以上是能夠實現到目前爲止，我會選擇B4。含義在控制我會做這樣的事情：

這（在代碼一個地方1個邏輯部分）結合可讀代碼，那並不產生任何不必要的冗餘碼，那並不需要任何難溶動態支票，是容易可重複使用等等。您能否確認/評論此解決方案？

來源

2014-10-28 Anonym

當爲偵聽器使用匿名實現時，以後無法在處理對象時將其移除，最終（以及您*將*具有這些情況）會導致內存泄漏。 – alterfox 2014-10-28 22:36:06

@alterfox：感謝您指點。 – Anonym 2014-10-28 22:52:01

@alterfox：這不是由GC處理的嗎？監聽器的列表是這種匿名監聽器的唯一參考，在組件處置期間它將被清空，對嗎？或者我也許會誤解。在這種情況下，我將爲此創建一個類併爲構造函數添加一個參數，這將決定哪個方法將處理它。 [也許有更好的解決方案，這是第一個跨過我的腦海] – Anonym 2014-10-28 23:02:08

說實話這個問題歸結到了一些問題......

你想重用？
你想配置嗎？
它們是自包含的嗎？也就是說，是否有其他人傾聽組件或需要在將來修改監聽器的結果動作？

我個人傾向於自我控制。給定動作/任務的單個監聽器。這使得我需要時更容易管理和更改。

如果我不需要可重用性（監聽者）或可配置性，那麼匿名內部類通常是首選。它隱藏了功能，並且不會使用小的一次性使用類來混淆源代碼。你應該小心它可以使源代碼難以閱讀。這當然假定這個任務是專門構建的（它是一個單獨的案例）。通常，在這些情況下，我更願意從實際執行工作的偵聽器中調用其他方法，這爲班級提供了一定的靈活性和可擴展性。通常情況下，你會發現自己希望修改組件的行爲，以便找到隱藏在匿名或私有內部類中的行爲。

如果您想要重用性和/或可配置性 - 也就是說，偵聽器執行的任務可以在整個程序中重複執行，或者通過庫隨時間重複執行，那麼您需要爲任務提供專用類。再次，我傾向於自給自足的解決方案，因此任何一個聽衆只做一項工作，更容易更改單個聽衆，然後通過if-else陳述的複合列表進行挖掘：P

這也可以是一系列的abstract監聽器，可以像操作建立功能，例如從表中刪除的行...

你可以考慮類似的Action API（見How to Use Actions有詳細介紹），這是自包含的工作單位，但其中還攜帶配置信息。它們被設計成與按鈕一起工作，如JButton s和JMenuItem s，但也可以與鍵綁定一起使用，使它們非常通用......

您問題的第二部分（關於MVC）取決於。我更願意儘可能將UI相關的功能保留在視圖中並且離開控制器。我寧願爲控制器/視圖交互提供我自己的專用監聽器，而不是讓控制器直接將監聽器設置爲組件，而是爲控制器通知控制器可能想知道的視圖更改，反之亦然。

想想這樣。您可能有一個登錄控制器和視圖，但控制器只關心從視圖中獲取憑據並在視圖發出請求時對其進行身份驗證，而不關心如何從視圖角度進行請求。這允許你爲不同的情況設計不同的視圖，但只要你維持視圖和控制器之間的契約，它就不會有什麼區別......但那只是我自己。

來源

2014-10-29 00:10:02 MadProgrammer

Java Swing GUI用戶操作處理

回答

相關問題