2

Suppose i have a class with 3 variables 

class User{
    private int userId;
    private String userFirstName;
    private String userLastName;
}

now, i could create it's setter methods like this

public User setUserId(int userId){
    this.userId = userId;
    return this;
}

it would allow me to do chaining like this 

User user = new User().setUserId(1).setFirstName("fName");

it has been advised to me not to create object this way because it's an anti-pattern. Basically, the reason that was given to me was that i'm using a setter to set the value of a variable and also, return the object itself(thereby violating Single Responsibility Principle), which i don't think is true. but nonetheless, another approach suggested to me is create a constructor with all the variables.

public User(int userId, String userFirstName, String userLastName){
    this.userId = userId;
    this.userFirstName = userFirstName;
    this.userLastName = userLastName;
}

and call it like this

User user = new User(1, "fName" , null);

LastName would be null as it was in previous case, which i don't suppose is also right(passing null as parameter value).
This is just one example. if i have like 10 different variables and i don't want to use setter in normal way(i.e. call each setter in a single line of code, after creating user object), could someone shed some light over which of the two ways to go about. (my primary concern is code should be smaller yet readable)

Shashi
  • 746
  • 10
  • 39
  • 3
    The rule that I follow is **pass the mandatory parameters in constructor and set optional parameters through setters**. – Sanjeev Kumar Nov 21 '15 at 19:13
  • I'd agree that using method chaining like you've shown doesnt seem to violate the Single Responsibility Principle. I think its fairly common to do this. The main benefit I can see of not using setters and setting fields using the constructor is that it makes the object immutable. I.e. the fields cannot subsequently be altered. – robjwilkins Nov 21 '15 at 20:01

2 Answers2

2

I'm not sure why that breaks the "Single Responsibility Principle"; your object is not changing anything but its state and/or identity.

There is another caveat: if your object doesn't need all the parameters, is it really that type or should be designed/fragmented into two (or more) objects? Let's say you are modeling a dog. Don't you need all what's required for it to be and behave like a dog? If not, then...what kind of animal/dog do you have; or, do you really have a dog? This has a lot of point of views, but I'm pretty sure you get it.

The same applies if your object needs too many parameters (Hibernate entities don't escape from this).

Anyway, make sure you initialize what's really needed. Then use the "setters" whenever required. You can achieve the same by using your initial approach. Have a look here for an example of the Builder pattern. Anyway, I'm a firm believer of immutability and in that case the Builder pattern violates that, but we should be flexible some times.

x80486
  • 6,627
  • 5
  • 52
  • 111
1

The rule is to use contructor for required parameters. However if you have a lot of required parameters, the builder pattern can be quite useful: When would you use the Builder Pattern?

The advantage is that the builder pattern doesn't violate the rule of required parameters in the constructor.

If you have a few required parameters it is probably better to not use the builder pattern.

Community
  • 1
  • 1
Albert Bos
  • 2,012
  • 1
  • 15
  • 26