是不是很好，有實例變量分配給一些值，而不是在構造函數中聲明

我有一個類用戶它具有實例變量與默認值。像下面提供是不是很好，有實例變量分配給一些值，而不是在構造函數中聲明

public class User{ 
    private String username=""; 
    private String password = ""; 
    private Boolean isValidUser = true; 
    private Boolean email = "[email protected]" 
    ........ 
}

現在我已經改變了我的課像

public class User{ 
     private String username; 
     private String password; 
     private Boolean isValidUser; 
     private Boolean email 
     ........ 

     public User(){ 
     email = "[email protected]"; 
     isValidUser = true; 
     ....... 
     } 
    }

我雖然保持這些默認值的構造函數是很好的做法。

我知道這很愚蠢問題= D但想知道你的意見。

來源

2016-09-26 ravi teja Kaveti

個人我不會這樣做，因爲它看起來像一個默認的構造函數在這裏沒有任何意義。我寧願堅持有價值的構造函數，就是這樣。但正如你可能已經注意到的，這是基於高度敏感的，我猜測它會被關閉，就像 – SomeJavaGuy

在多構造函數的情況下，直接初始化字段而不是在所有構造函數中可能更好。 – Tokazio

相關，可能的重複：http://stackoverflow.com/questions/1994218/should-i-instantiate-instance-variables-on-declaration-or-in-the-constructor – Arc676

問題是，你不會放下課程「隨你去」。一門課程的確切設計只是整個設計中的一個小方面。

來自DDD（域驅動設計）首先要考慮的是您打算構建的模型。含義：爲了在系統中對用戶進行建模，您正在創建一個類用戶。這意味着你（以及參與該項目的所有其他人員）需要非常清楚地瞭解「用戶的真實身份」。

例如：您的字段似乎都不是最後的。但我很確定：在任何合理的用戶模型中，用戶將具有某些屬性，從不更改;例如特定的用戶ID。另一方面，給新用戶分配一些「默認」電子郵件地址似乎是非常錯誤的;並聲明這些用戶是「有效的」。與此相反的。

我在說的實質是：你應該專注於創建一個一致的模型。然後，當你真的瞭解你的系統正在用「用戶對象」和這些用戶擁有哪些屬性;那麼你可以看看很多可能的模式，以後如何實際創建這樣的對象。

您的方法是通過您的實施細節來定義您的系統。並列出 - 這不是一個好主意。

來源

2016-09-26 11:05:24 GhostCat

是不是很好，有實例變量分配給一些值，而不是在構造函數中聲明

回答

相關問題