CODEWITHSUNDEEP
javaconstructor
Nikitha
Nikitha

Reputation: 373

No arg constructor or arg constructor

In my program I read a fixed length file, stored each string in a local variable, and then stored every value into a class type array list. For creating the object of an array list, I used argument constructor with all the variables. The below code demonstrates this.

String a = "text1";
String b = "text2";
SampleModel sm = new SampleModel(a,b);
ArrayList<SampleModel> sampleList = new ArrayList<>();
sampleList.add(sm);

I find this absolutely right but my colleague asked me to change it to a no arg constructor and call getters and setters instead. That would be like below.

SampleModel sm = new SampleModel();
ArrayList<SampleModel> sampleList = new ArrayList<>();
String a = "text1";
String b = "text2";
sm.setA(a);
sm.setB(b);
sampleList.add(sm);

Is there any reason to prefer a no arg constructor over argument constructor? (My program has around 15 variables)

Upvotes: 4

Views: 1479

Answers (5)

Andy Thomas
Andy Thomas

Reputation: 86391

It depends on how the class will be used.

For example, an immutable class will need a constructor that takes arguments, and no setters.

But a Java Bean will need a no-argument constructor, and setters.

Some things to consider:

  • Encapsulation can be valuable. Other than special cases like JavaBeans, usually the interface of the class can be designed based on the desired interactions, not on the current set of data members.
  • Methods have names. Java does not support named arguments. Method names communicate how an actual parameter is being used, in the calling code. If your class has more than a handful of parameters, passing them via methods can result in more readable calling code.
  • Immutable classes have value. If you're adding named setters directly in your class, it won't be immutable. The builder pattern allows you to accept construction parameters even for immutable classes.

Upvotes: 7

The Roy
The Roy

Reputation: 2208

Quotation from Fowler and Beck book: "Refactoring"

Long Parameter List

In our early programming days we were taught to pass in as parameters everything needed by a routine. This was understandable because the alternative was global data, and global data is evil and usually painful. Objects change this situation because if you don't have something you need, you can always ask another object to get it for you. Thus with objects you don't pass in everything the method needs; instead you pass enough so that the method can get to everything it needs. A lot of what a method needs is available on the method's host class. In object-oriented programs parameter lists tend to be much smaller than in traditional programs. This is good because long parameter lists are hard to understand, because they become inconsistent and difficult to use, and because you are forever changing them as you need more data. Most changes are removed by passing objects because you are much more likely to need to make only a couple of requests to get at a new piece of data. Use Replace Parameter with Method when you can get the data in one parameter by making a request of an object you already know about. This object might be a field or it might be another parameter. Use Preserve Whole Object to take a bunch of data gleaned from an object and replace it with the object itself. If you have several data items with no logical object, use Introduce Parameter Object. There is one important exception to making these changes. This is when you explicitly do not want to create a dependency from the called object to the larger object. In those cases unpacking data and sending it along as parameters is reasonable, but pay attention to the pain involved. If the parameter list is too long or changes too often, you need to rethink your dependency structure.

Upvotes: 0

flakes
flakes

Reputation: 23624

It might just be that it's easier to see whats going on than having a large comma separated list. This might also be a nice place to use Double Brace Initialization:

String a = "text1";
String b = "text2";
SampleModel sm = new SampleModel() {{
    setA(a);
    setB(b);
}};
ArrayList<SampleModel> sampleList = new ArrayList<>() {{
    add(sm);
}};

Upvotes: 0

Hypino
Hypino

Reputation: 1248

A constructor that takes arguments is essentially for convenience (although that's not always the case if the object requires arguments in order to be constructed properly, it is here without seeing anymore context); it's doing the exact same thing as the set methods are doing.

There is no reason to not have a constructor take arguments, as long as those arguments "make sense" in the context of the object. In other words, it's more of a semantics thing to consider than a correctness thing.

If the constructor is:

public SampleModel(String a, String b)
{
    this.a = a;
    this.b = b;
}

It probably doesn't make a difference.

Upvotes: 1

TangledUpInBlue
TangledUpInBlue

Reputation: 746

Whether I use accessors and mutators for a class variable depends on two things:

  1. Whether the variable is essential or optional to the object.
  2. Whether it might ever change in the course of using the object, or whether it is final.

Variables that are necessary and final should be in the constructor, in my opinion, and should not have mutators. Variables that are optional should have accessors and mutators. Variables that are essential but might change are up to your discretion. I would probably put them in the constructor, but use a Builder design pattern to avoid having a long list of arguments for the constructor.

Upvotes: 2

Related Questions