創建許多新的實例與重用它們？

Question

我在VB.NET Windows窗體應用程序中有多個業務實體。現在，它們在應用程序啓動時實例化並在需要時使用。他們掌握商業實體和存儲和檢索數據的方法的描述。長話短說，他們有點重的對象（他們有一些內部字典和對其他對象的引用）創建並保存在一個叫做「BLogic」的大全局變量中。

我應該重構這個，以便每個對象在需要時創建並在超出範圍時釋放？那麼UI上的每個事件都可能會創建一些這樣的對象。

我是否應盡力減少新對象的創建或最大限度地減少靜態和全局對象的數量？通常我想盡量減少每個變量的範圍，但是我應該專門處理這些業務邏輯對象嗎？

Answer 1

讓我們來看看你提出的兩個方案：

單一的全球實例

優點：

• 少每種方法的性能成本，因爲對象已經創建
• 無需弄清楚如何傳遞數據

個

缺點：所創建的對象，但從來沒有使用過

• 機會。這是對內存和性能的浪費。這可以通過使用延遲初始化來緩解，該初始化將在首次使用對象時創建對象，但仍保留單個全局創建的實例。
• 多線程處理的問題，如確保數據的一致性（潛在的性能和開發成本）

每個功能情況

優點獨特之處：

• 每個函數獲得它自己的拷貝，不不得不擔心其他功能可能同時在做什麼。
• 如果對象沒有經常被創建和銷燬，那麼您的程序的總內存使用量可能會更低。

缺點：

• 根據需要多長時間來創建對象，你可以在用戶界面的響應問題。
• 根據創建對象的方式，您可能必須等待另一個函數完成創建對象，然後才能創建副本。

這並不是一個詳盡的清單，但它確實指出了我可以看到它們的主要權衡。顯然，你對這種情況瞭解得更多，哪些權衡是可以接受的。一些明智選擇的全局變量可能是有用的，但像大多數人一樣，我會從大量的全局變量中剔除，除非它們表示只能有一個變量，比如SerialPort，或者整個應用程序應該只有一個變量，就像一個ApplicationSettings類。

不要低估你的時間（現在和以後當你回來維修時）作爲成本。有時候一個「更好」的解決方案實際上可能會更糟，因爲它需要很長時間才能實現通常，「足夠好」原來就足夠好了。

Answer 2

是的，您應該重構僅在需要時分配對象，並在不再需要時處理它們。除非有特定和可衡量的性能要求，否則這總是一個很好的設計選擇。

推遲分配直到絕對需要的優點是，在許多（大多數？）情況下，對象永遠不會被分配。拖延付錢！ ;>您的應用程序運行更加精簡，整個系統應該更少徵稅和更快捷。沒有人喜歡使用記憶豬。

根據需求分配的缺點是它可能會延遲用戶反饋/響應，這會令人不快。如果你有一個對象需要花費大量的時間來構造或初始化（比如說，通過網絡加載數據），如果用戶期望立即看到結果，那麼這對於按鈕點擊分配可能不是很好的匹配點擊按鈕後。如果您可以立即調出用戶界面來響應按鈕點擊，但是新窗體上的控件會盡快從網絡數據中自行填充（並指示它們正在加載某些內容），那麼這不是什麼問題。點擊和UI響應之間的「相當長的時間」的一般UI指標通常約爲半秒。