Constructors - lots of paramters or none and use of set methods

Starting out with immutable classes is typically a good idea. (according to Effective Java). I like to do things that way when I can.

You should also check out the builder pattern.

As it encapsulates your initialization and allows you to add more parameters without affecting the constructors signature.

EDIT: Here is an example based on your code, It might be a cross between C# and java but I think you will get the idea...

public class Person {
    private string firstname;
    private string surname;
    private Address homeAddress;
    private PhoneNumber homeNumber;

    public Person( Builder builder ) {
        super();
        this.firstname = builider.firstname;
        this.surname = builder.surname;
        this.homeAddress = builder.homeAddress;
        this.homeNumber = builder.homeNumber;
    }

    pubilc static class Builder {
        private integer id;//required field.
        private string firstname;//optional field.
        private string surname;//optional field.
        private Address homeAddress;// optional field.
        private PhoneNumber homeNumber;// optional field.

        public Builder( integer id ) {
            super();
            if ( id == null ) {
                //deal with it.
            }
            this.id = id;
        }
        public Builder setFirstname( string firstName ) {
            this.firstname = firstname;
            return this;
        }
        public Builder setSurname ( string surname ) {
            this.surname = surname;
            return this;
        }
        public Builder setHomeAddress( Address homeAddress ) {
            this.homeAddress = homeAddress;
            return this;
        }
        public Builder setHomeNumber( PhoneNumber homeNumber ) {
            this.homeNumber = homeNumber;
            return this;
        }
    }
    // Person.getXXX() goes here.

    public static void main( String...args ) {

        Person.Builder builder = new Person.Builder( new integer( 123 ) );
        builder.setFirstname( "foo" ).setSurname( "bar" ).setHomeAddress( new HomeAddress() ).setHomeNumber( new PhoneNumber() );

        // always the same
        Person person = new Person( builder );
    }
}

I also recommend the Builder pattern, however I prefer to do it this way:

public class Person {
    private int id;
    private String firstname;
    private String surname;
    private Address homeAddress;
    // etc.

    private Person() {// IMPORTANT, private constructor
    }

    public static class Builder {
        private Person person;

        public Builder(int id) {
            if (id == 0) {
                //fuck it
            }
            person = new Person();
        }

        public Builder setFirstname(String firstName) {
            person.firstname = firstName;
            return this;
        }

        public Builder setSurname(String surname) {
            person.surname = surname;
            return this;
        }
        // etc.

        public Person build() {
            // don't return the object if it was not created correctly... for instance:
            if (person.firstname == null) {
                throw new IllegalStateException("You are a fool");
            }
            return person;
        }
    }

    public static void main(String... args) {
        Person person = new Person.Builder(666)
                .setFirstname("foo")
                .setSurname("bar")
                .build();
    }
}

Main difference with regards to the previous response is that:

• You can't create a Person unless you use a Builder
• The builder knows when a person is ready, otherwise it won't return anything.

It depends on whether the data elements are required for the object to be well defined or if they are completely optional.

My personal preference is for the constructor to have parameters for all the required data elements and use set methods for everything else. I also declare the default (parameterless) constructor to be private. That way the compiler guarantees that no one will create an incompletely defined object.

If firstname and lastname are required but address and phone number are optional, I would do the following:

private string _firstname;
private string _surname;
private Address _homeAddress;
private PhoneNumber _homeNumber;

private Person()
{
    // Ensure unitialized Person cannot be created
}

public Person(string firstname, string surname)
{
    _firstname = firstname;
    _surname = surname;
}

// getters and setters omitted for brevity

The disadvantage of using the Builder pattern as recommended in other answers is that the completeness check is deferred to runtime. If you have a code path that is very rarely executed and you change Person so that more data is required, then you could deliver code that will fail in the field. With my approach, you will know about the problem the next time you try to compile your code.

The answer isn't necessarily language agnostic, because it would be silly not to use the facilities of your language to address this issue...
So your question is valid in Java and other intermediate language, but is more pointless in some higher level languages.

I am thinking of Scala, where you have indeed named and default parameters, allowing to have constructors with lot of parameters while keeping readability: you name the parameters on the call site, which similar to the chaining of sets, but safer as mandatory parameters (without default) must be present.

On the other hand, you can also use type tricks (called phantom types, if I understood correctly the articles I have read, but not totally assimilated...) to force a builder to get all the required elements. When I write "force", I mean "enforced by the compiler", ie. your code must be correct at compile time, it isn't just checked at run time. Powerful.

I won't address your specific question (solution working for all languages), the answers I see are much better than the one I could make, but I thought I should mention interesting alternatives to your question.

• Making a constructor do as less work as possible is good. To me, simply assigning parameters to local fields is not work. That to me, is zero work - No logic is involved.
• Depending on your programming language, marking the fields as final is good, if you are not modifying them. My big reason for this is for readability - its immediately clear that the final fields are the easy bits - can't be modified and less hanging threads to keep in my thread as I read the rest of the code. This doesn't seem like a big deal for your current class, but I am guessing that the your code snippet is part of a much bigger class, and even if it wasn't, its pretty much something I always do.
• Exposing the setters just to use them by the builder and not anywhere else introduces more complexity(see point 2).
• Using the builder brings more verbosity. I wouldn't use it just for optional fields - constructor overloading/passing in null is much cleaner for this. In general, I use the builder pattern when the construction process is more laborious then just setting some fields.
• Too many paramters is a code smell but 4 parameters seems okay. Especially, if they actually seem like they belong to this class, and they have different types amongst them(not all are strings for e.g.).

My conclusion: I would just mark the fields final and stick with your option 1. :)