2

I have a Class USER which has instance variables with default values. like give below

public class User{
   private String username="";
   private String password = "";
   private Boolean isValidUser = true;
   private Boolean email = "sample@gmail.com"
  ........ 
}

now i have changed my class like 

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

      public User(){
         email = "sample@gmail.com";
         isValidUser = true;
         .......
      }
  }

I though keeping those default values in constructor is good practice.

i know it's stupid Question =D but wanna know your opinion.

kavetiraviteja
  • 2,058
  • 1
  • 15
  • 35
  • personally i wouldn´t do it, because it seems like a default constructor doesn´t make any sense here. I´d rather stick to the constructor having values and that´s it. But as you might have noticed, this is highly oppinion based and i´d guess it will be closed as though – SomeJavaGuy Sep 26 '16 at 10:47
  • In case of multiple constructors, it could be preferable to init the fields directly instead of in all the constructors. – Tokazio Sep 26 '16 at 10:48
  • 2
    Related, possible duplicate: http://stackoverflow.com/questions/1994218/should-i-instantiate-instance-variables-on-declaration-or-in-the-constructor – Arc676 Sep 26 '16 at 10:49
  • @Tokazio Assuming the constructors want to initialize to the same value. If not, then they should do their own initialization instead. – Andreas Sep 26 '16 at 10:50
  • @Andreas in this case, you've no other choice yes – Tokazio Sep 26 '16 at 10:54
  • @Tokazio even though in multiple constructors case which have same initialisation code . we can write a single method init() and just call this method in every constructor instead of hardcoding the values at instance level. – kavetiraviteja Sep 26 '16 at 10:59
  • yes a final method. i wrote 'it could be preferable' and more readable because at the top of the java file. – Tokazio Sep 26 '16 at 11:02

1 Answers1

2

The point is that you don't put down classes "as you go". The exact design of a class is just one small facet within your overall design.

Coming from DDD (domain driven design) the very first thing to consider is the model that you intend to build. Meaning: you are creating a User class for the purpose of modelling Users within a system. This means that you (and all the other people involved in that project) need a very clear understanding what a "user really is".

Example: it seems that none of your fields are final. But I am pretty sure: in any reasonable model of users, a user will have certain properties that never change; for example a specific user id. And on the other hand; it seems very much wrong to assign some "default" email address to new users; and declare those users to be "valid". To the contrary.

What I am saying in essence is: you should focus on creating a consistent model first. And then, when you really understand what your system is doing with "User objects" and which properties those users have; then you look into the many possible patterns how to actually create such objects later on.

Your approach is to define your system by the details of your implementation. And as lined out - that is not a good idea.

GhostCat
  • 137,827
  • 25
  • 176
  • 248