Various params method signature versus one object param method signature

Question

I need to construct objects with many properties. I could create one constructor with one param for each property:

class Friend{

    constructor(name, birthday, phone, address, job, favouriteGame, favouriteBand){
        this.name = name;
        this.birthday = birthday;
        this.phone = phone;
        this.address = address;
        this.job = job;
        this.favouriteGame = favouriteGame;
        this.favouriteBand = favouriteBand;
    }

}

or I could recieve one param with a literal object or an array with all the values:

class Friend{

    constructor(descriptor){

        this.name = descriptor.name;
        this.birthday = descriptor.birthday;
        this.phone = descriptor.phone;
        this.address = descriptor.address;
        this.job = descriptor.job;
        this.favouriteGame = descriptor.favouriteGame;
        this.favouriteBand = descriptor.favouriteBand;
    }

}

In which case should I use each one? Is there a design-pattern about this subject?

I'm interested in OOP. I'm using Javascript but it could be wrote in any other language supporting OOP (PHP, Java, C++, Python, any other possible)

https://refactoring.com/catalog/introduceParameterObject.html — jaco0646, Apr 06 '18 at 14:49

davidxxx · Accepted Answer · 2018-04-04T21:10:14.777

The first one seems more explicit for the clients as each parameter is defined in the constructor declaration.
But this way is also error prone as you have many parameters and some parameters have the same type. The client can easily mix them as these are passed to.
So in this specific case, using a literal such as constructor(descriptor){...} seems clearer.

I am not sure that this type of constructor be a design pattern. It is rather a constructor flavor that depends on the requirement but also on the language used.
In JavaScript, it is common enough as it is straighter and it avoids writing boiler plate code for setters method or a builder constructor.
But in other languages as Java, defining a constructor with so many arguments is a also bad smell but using a literal is not a possible alternative either. So using setters or a builder constructor is generally advised.

score 1 · Answer 2 · answered Apr 04 '18 at 21:25

If you think about it that many fields in a single object is a slightly annoying pattern. It's not a terribly bad smell--let's call it slightly oderous.

The one case I've seen for having many fields like this is Java Beans or pojos. These tend to be a class with a lot of fields with annotations telling various services how the fields should be used. These don't really need complex constructors because they are usually created using the annotations for guidance.

Other classes--the ones with logic in them--don't usually need this many initialized fields.

When they do need this, I'd lean heavily towards factory pattern & immutability.

Intellij has an add builder pattern refactor that would be good for this, there is probably one for eclipse/netbeans as a plugin but I haven't looked too hard for it.

score 0 · Answer 3 · answered Apr 04 '18 at 21:15

Wow the 3rd edition just came out, but the correct answer for this is you should use Bloch's Static Builder Pattern, which solves both the problem you note here, and the related (maybe more important one) of how to make many of the fields immutable.

Read about it here.

Various params method signature versus one object param method signature

3 Answers3