In your opinion what is the best way to construct an object given the two examples below:Option 1: Lots of parametersprivate string firstname;private string surname;private Address homeAddress;private PhoneNumber homeNumber;public Person(string firstname, string surname, Address homeAddress,               PhoneNumber homeNumber){    _firstname = firstname;    _surname = surname;    _homeAddress = homeAddress;    _homeNumber = homeNumber;}public string getFirstname(){    return firstname;}public string getSurname(){    return surname;}public Address getAddress(){    return address;}public PhoneNumber getHomeNumber(){    return _homeNumber;}Option 2: no parameters and use of set methodsprivate string firstname;private string surname;private Address homeAddress;private PhoneNumber homeNumber;public Person(){}public string getFirstname(){    return firstname;}public void setFirstname(String value){    firstname = value;}public string getSurname(){    return surname;}public void setSurname(String value){    surname = value;}public Address getAddress(){    return address;}public void setAddress(Address value){    address = value;}public PhoneNumber getHomeNumber(){    return _homeNumber;}public void setHomeNumber(PhoneNumber value){    _homeNumber = value;}Which method do you prefer?  In my mind, option 1 is better because you know that the state of your object cannot be changed.  I believe this is called immutability and is something that should be desired?  On the other hand, it can quickly get out of hand and ugly if you have more than a handful of parameters.I am aware that some languages such as C# have nice features that would probably make option 1 more appealing such as named and optional parameters however this question was prompted while dealing with Java code.Update: Thank you for all of your suggestions.  I will comment on each answer individually but a few answers suggested using a factory method instead of having the constructor do all of the work.  This was actually the pattern I was using because it is a standard at work but I've never really seen the advantage of it as opposed to using the constructor to do the work.  This is more how the code looked:private string firstname;private string surname;private Address homeAddress;private PhoneNumber homeNumber;private Person(){}public Person factoryCreate(string firstname, string surname, Address homeAddress,                             PhoneNumber homeNumber){    Person person = new Person();    person.setFirstname(firstname);    person.setSurname(surname);    person.setHomeAddress(homeAddress);    person.setHomeNumber(homeNumber);    return person;}public string getFirstname(){    return firstname;}public void setFirstname(String value){    firstname = value;}public string getSurname(){    return surname;}public void setSurname(String value){    surname = value;}public Address getAddress(){    return address;}public void setAddress(Address value){    address = value;}public PhoneNumber getHomeNumber(){    return _homeNumber;}public void setHomeNumber(PhoneNumber value){    _homeNumber = value;}From the discussion about having constructors do little work and using builders, I can see why having the factory method is a good one.  My understanding of factory methods was that they were used to create a class given a few options.  For example, if you have an Employee class and that is sub-classed by FullTimeEmployee and PartTimeEmployee, you would have a factory() method on Employee to deal with creating the more concrete class.
Constructors - lots of paramters or none and use of set methods
c#;constructor
When building objects, having a constructor that does very little is ideal.  This becomes especially true once you are testing your objects with unit tests.Like other suggestions, I would leave the proper construction of the object to a builder or factory method.  I would emphasize that you should only include parameters that are required for it to be a proper object, and that generally you want no more than 7 (give or take 2) parameters.  If you have more parameters than that, your class may be trying to do too much.However, things like an ID that relates to a database field (or other storage mechanism) are better left to be set by the Data Mapper, Repository, etc. that you are using.In my native programming language, it would look something like this:class Person{    private $_id; // optional (not necessary for a Person... set once stored)    private $_name; // required    private $_address; // optional    /**     * @param $name - In this example, I'm just going to pretend like this is required.     *                It probably doesn't make sense for there to be an instance of a      *                Person without a name.     * @return Person     */    public static function factory( $name )    {        $Person = new Person();        $Person->setName($name);        return $Person;    }    public function setId($id)    {        $this->_id = $id;    }    public function getId()    {        return $id;    }    public function setName($name)    {        $this->_name = $name;    }    public function getName()    {        return $this->_name;    }    public function setAddress($address)    {        $this->_address = $address;    }    public function getAddress()    {        return $this->_address;    }}When creating a Person:$PersonRepository = new PersonRepository();$Person = Person::factory('Sarah');$PersonRepository->save($Person);   // This generates an ID for $Person before savingWhen retrieving a Person:$PersonRepository = new PersonRepository();$Person = $PersonRepository->getById($id); and the Repository in this case would be responsible for doing something like...$Person = new Person();$Person->setId($storageResult['id']);$Person->setName($storageResult['name']);$Person->setAddress($storageResult['address']);return $Person;