這是更理論上的問題。我寫了與我的朋友簡單聊天。我們有幾個類，但最重要的是客戶端（處理網絡的東西）和GUI（不言自明）。Java - 最好是直接訪問其他對象組件或通過方法？
現在，我將消息寫入JTextArea。我想問一下，從OOP理論來說，發送給客戶端引用JTextArea並直接向它附加文本會更好一些，還是更好地在GUI中創建函數，使其相同並從客戶端調用它？當然信息來自服務器。
我知道最有效的方法是第一，但我相信它不是適當的面向對象的方式。我發現OOP比程序效率低，不是因爲它在抽象上更復雜，而是因爲許多OOP標準看起來似乎不夠用。謝謝。
您應該是encapsulate GUI的功能。客戶不應有任何內部工作知識。相反，你應該提供一個語義上有意義的公共方法來描述它將執行的任務 - 在這種情況下更新顯示。
理想情況下，您應該有一個表示GUI操作的接口 - 這將使客戶端與GUI分離，並且意味着您可以使用多個UI來實現接口，並且客戶端不關心它使用的是哪個UI。
桌面應用程序通常由業務層和表示層組成。 GUI屬於表示層。我認爲客戶屬於業務層。
業務層不應該知道表示層的任何內容。
在這種情況下，客戶端可以引入一個接口。例如：
interface MessageListener {
void handleNewMessage();
}
然後，我們可以有一個觀察者模式。客戶端調用已註冊的MessageListener。 GUI實現MessageListener和註冊表到客戶端。
對此：
我所知道的最有效的方法是 第一，但我相信它不是 適當的OOP方式。我發現OOP 效率低於程序效率，而不是 ，因爲它更復雜，因爲抽象是 ，但是因爲許多OOP 標準看起來似乎不夠用。 謝謝。
對於您所寫的所有代碼中大約99％，效率是完全無關緊要的，因爲效率不足以注意到任何低效率。這裏的情況當然是這樣的：圖形用戶界面事件處理代碼是關於性能最高的 - 不加批判的代碼，因爲用戶甚至不會注意到小於1/100秒的延遲，並且在現代硬件上是永恆的。
此外，對於您所寫的所有代碼的全部百分比，完整和正確的問題不僅僅是效率。沒有人關心你的代碼做錯了什麼。當可維護，清潔，解耦時，生成正確和完整的代碼要容易得多。這正是面向對象及其慣例試圖（並且通常會）變得更容易。