使用集中變量的良好編程習慣

當處理需要相同變量實例的多個類時，編寫實踐是否很好，以創建一箇中心變量？使用集中變量的良好編程習慣

chatWindow.variables.username = userField.getText();

例如：

我有一類的變量一組量
我有一個需要相同的變量另一個類
，另一個需要相同的變量第一個

所以我有三個類都使用變量的相同實例

我只創建使用第一類的變量類的實例（1）

我訪問使用類（2），（3）通過類（1）

實施例這些變量：（而在classTwo（））：

classOne.variableClass.VariableName = false;

編輯：在基本形式，我的問題是，如果它是確定以使中央「變量班」，並使用其他類通過主訪問它的同isntance類。

我知道我的問題很難理解，但我確定有另一種更簡單的方法。我嘗試通過第二個和第三個類的構造函數傳遞第一個類的同一個實例，但是我的解決方案似乎更簡單一些。

來源

2012-09-07 Andrei0427

你可以給你的類的更多細節？它可能會更容易幫助 – RNJ

*你是什麼意思*需要相同的變量*？你想在其他類中使用這些變量，還是隻是將它們作爲其他類的屬性繼承？ – Sujay

你問的是** [單身（反）模式]（http://www.oodesign.com/singleton-pattern.html）**。不推薦使用，請參閱** [this]（http://programmers.stackexchange.com/questions/148108/why-is-global-state-so-evil）**問題。 –

這聽起來像feature envy ...這樣做聽起來像是你的模型有問題。

如果有一組變量需要在多個類中更改，它可能應該成爲一個對象（可能甚至是一個實體）。但是你應該考慮如果你需要在其他類中改變這些值，你可能需要在同一個類中加入一些邏輯（做驗證檢查等等）。

有一個額外的類只是爲了保持變量通常被認爲是一種代碼氣味，稱爲貧血域。然而，有些案例確實需要它，無論如何它可能都是一個品味問題。在那種情況下，你的班級只不過是一個榮耀的結構。

來源

2012-09-07 08:14:26

爲surcemaking鏈接+1 - 這是一個很好的網站！ – RNJ

聽起來好像你已經很好地隔離了你的類。類可以修改其他類變量，但我會避免在一個地方存儲可變變量。這使得事情看起來像全局變量，這是非常難以管理和最好的避免。有關詳情，請參閱here。查看Law of Dementer，這有助於保持程序中的鬆耦合。

來源

2012-09-07 08:07:12 RNJ

由於缺乏示例，我不太清楚您需要什麼，但也許註冊表模式是您所需要的。

基本上，你創建一個靜態的「全局」類，用於保存你所需要的所有變量在整個應用程序現在

public abstract final class VarRegistry { 
    public static final String var1 = "val1"; 
    public static final int var2 = 2; 
}

，在需要訪問這些變量的所有類，你可以輕鬆地訪問和修改他們：

VarRegistry.var1 = "test";

等一秒鐘，然後再去編碼：這不是很推薦使用這樣的「全局」變量。它破壞了數據封裝，因爲你永遠不知道這些變量何時被改變以及由誰改變。

您可能會更好地重構您的程序，以支持更安全的模式，以正確記錄您的數據，例如，依賴注入。

來源

2012-09-07 08:07:52

我會用一個實用類的枚舉。抽象類可以有子類。 ;） –

'final'它是，然後 –

不能'抽象final'我會使用public enum VarRegistry {;'這是最後一個私有構造函數。 ;） –

最好的做法是使用依賴注入並傳遞所需的所有資源，而不是讓類找到他們想要的。

使用全局變量更簡單，但隨着應用程序的增長以及您想要使用單元測試，這些是一個真正的痛苦，因爲管理和維護它們變得更加困難。

來源

2012-09-07 08:08:00

每個問題都有自己的最佳折中，你應該問自己一系列的問題。（2）和（3）需要準備好只能訪問（1）還是還需要寫入訪問權限？

什麼你實際上是在做（創建（2）和（3）（1）似乎不錯，建設者模式，你創建一個你從來沒有直接訪問istances）

如果需要寫訪問應該（2）被通知（3）（或反之）的變化？

一般來說，您應該儘可能限制來自「子類」的交互（理想情況下，儘量避免共享某些東西，如果可能，當然，但通常是這樣），因此從內部（1）也比從（2）和（3）中訪問（1）更好的解決方案。

那種限制增加代碼的可維護性，並刪除/減少類似問題的值變化的通知，誰擁有誰等

基本上，如果用戶需要warry只有（1）和所有其他的東西在內部處理你（Pimpl idiom對你說什麼都沒有？）

你也可以像（2）和（3）那樣對（1）進行擴展，這樣就像戰略模式一樣。其優點是隻需要（1）需要考慮事項，但如果將來需要進一步完善（1），您已經準備好了該策略，並且可以以最小的努力進行更新。（我總是注意到，在您可以編寫的每個代碼中總是存在多個模式）。

到底你是誰，知道所有的代碼細節的唯一，總是問自己，如果你可以提高代碼的可維護性，便於閱讀等，在需要可能的升級等

來源

2012-09-07 08:23:14 Rax

@Truth：這不是一個Singleton，而只是一個引用其他類的類，即使是一個SceneGraph也有類似的結構，並且有多個孩子引用它們的父類。 – Rax

使用集中變量的良好編程習慣

回答

相關問題