Dreamer
Dreamer

Reputation: 7549

Is there any performance concern if too many parameter in a constructor?

I know it is not good design and I would rather use setter/getter if there is the choice. but I am writing a JPA entity and need this constructor for JPQL purpose, so in short I have to use constructors to initiate values for fields and embedded entities as well.

So I have to make about 40 parameters in the entity's constructors and have to let JPA use the constructor pretty frequently. I have been search online and haven't found anything stating that over-sized parameter list in java constructor may cause performance issue, but may be I didn't do enough homework.

So any advice is appreciated, performance is the only concern. thanks

Upvotes: 0

Views: 1049

Answers (3)

Angular University
Angular University

Reputation: 43127

Is there any performance concern if too many parameter in a constructor? There is nothing to worry about in that regard, there is no performance concern regarding this.

This is because the overhead of the query execution itself (once it reaches the database) plus the network overhead involved in sending the query to the network and receiving the data back is orders of magnitude higher than any penalty introduced by too many parameters in the constructor.

The reason to try to find an alternative would be code maintainability. You are probably in the presence of a highly denormalized table with many columns. This means that the database line can usually be split into several embeddables. The example bellow shows how 4 related columns could be grouped in an embeddable Address class:

@Entity
@Table("MANY_COLS_TABLE")
public class User {
   private Long id;
   @Embedded
   private Address address;
}

@Embeddable
public class Address {
    private String streetAdress;
    private int number;
    private String city;
    private ZipCode zipcode;
}

Upvotes: 0

StriplingWarrior
StriplingWarrior

Reputation: 156748

performance is the only concern

The issues with oversized parameter lists have practically nothing to do with performance--your performance will probably be as good or better than if you used setter methods to set up your object. Of course, as in all performance-related cases, the best advice is to try it, and benchmark it, and see if you can measure any difference. If this isn't a part of your code that you've identified as slowing things down, then performance shouldn't be a concern for you at all, much less your only concern.

However, having any method or constructor with such a large list of parameters makes your code unmaintainable and error-prone, and you should be seeking other options purely for the sake of code maintainability.

Upvotes: 4

Rogue
Rogue

Reputation: 11483

To simplify constructing an object, you should use a Builder pattern:

public class SomeComplexClass

    public static class SomeComplexClassBuilder {

        /* fields to set for the constructor */

        /* getters and setters for those fields*/

        public SomeComplexClass build() {
            //verify the fields are all correct for the object
            return new SomeComplexClass(/* pass the necessary fields*/);
        }

    }

    private SomeComplexClass(/*arguments*/) {...}

}

Then you can construct using the builder:

SomeComplexClass obj = new SomeComplexClass.SomeComplexClassBuilder()
                                           .setSomething(/*argument*/)
                                           .setAnother(/*argument*/)
                                           .build();

You can chain the methods to return the builder object for doing all that:

public SomeComplexClassBuilder setField(Object argument) {
    this.argument = argument;
    return this;
}

Upvotes: 0

Related Questions