I know this has been asked a lot of times but we are talking about entity classes here. Plain dumb objects containing nothing but primitives for properties. The purpose here is to store data. Our entity can be created in a variety of ways, we never know which set of properties will have a value, it is given by real life. Now somebody says that the right way to do it is the use constructors only, listing all possibilities of properties having a value or not. I guess it would make the number of constructors n! if we have n properties. This is obviously not even possible in every case because there can be only one constructor with the same number and same types of parameters. I say there is nothing wrong with setters, that way you just set whatever you got, it's more readable and cheaper.

  • 1
    see also When should the builder design pattern be used?
    – gnat
    Jul 20, 2017 at 9:05
  • @gnat: Not even close to a duplicate Jul 20, 2017 at 15:37
  • @GregBurghardt totally a duplicate because it clarifies the main point made by OP: "it would make the number of constructors n! if we have n properties"
    – gnat
    Jul 20, 2017 at 15:44
  • I think the OP is trying to decide if using public setters is OK for an entity class, or if you need constructors to pass in values. Jul 20, 2017 at 15:53
  • yes, and duplicate addresses just that, by showing how to use constructors when one needs to pass more than 2-3 values
    – gnat
    Jul 20, 2017 at 16:47

1 Answer 1


Is there a reason that you make your objects mutable? If not, then you have to use a constructor.

When it comes to a number of constructors:

  • Instead of overloads, use optional arguments if your language sorts them. This reduces the number of constructors to one in your case.

  • Check why so many properties are optional. It is rare to have a lot of optional properties, so it might be that there is either a misunderstanding of the business domain, or a problem with the schema of your data.

  • If you have too many properties (optional or not), you need to split your classes by grouping together the properties which represent a separate object within your original entity. For instance, Order doesn't have to have the properties such as the city or the post code of the shipping address: instead it should have only one field pointing to the object of type Address.

  • The reason so many properties are optional is because we are talking about user data coming from a form and for privacy reasons it is up to the user to supply data, so apart from a few basic properties, the majority is optional. Is it still okay to want to reduce the number of constructors and perhaps have only one or two, allowing the passing of nulls?
    – stevie
    Jul 20, 2017 at 9:45
  • @stevie: It depends on the actual case. If you can edit your question by providing one of the classes you are talking about, it may help. Jul 20, 2017 at 10:38
  • you can use a struct to make an immutable with setters in c#
    – Ewan
    Jul 20, 2017 at 11:18
  • @stevie: I see a big difference between optional members in a entity class (the field may or may not exist), and form entries that the user is allowed to leave blank. Those latter ones can very well correspond to a required member of an entity class where blank/empty string is a valid value. Jul 21, 2017 at 10:55
  • 1
    @stevie: Would it make a difference for you if the empty string or null value would be provided to the entity anyway? That way, the entity class can work with just a single constructor and the UI-handling code doesn't need to have the complication of filtering out the blank entries. Jul 21, 2017 at 14:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.