0

This question already has an answer here:

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.

marked as duplicate by gnat, BobDalgleish, David Arno, Thomas Owens Aug 15 '17 at 12:47

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    see also When should the builder design pattern be used? – gnat Jul 20 '17 at 9:05
  • @gnat: Not even close to a duplicate – Greg Burghardt Jul 20 '17 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 '17 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. – Greg Burghardt Jul 20 '17 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 '17 at 16:47
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 '17 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. – Arseni Mourzenko Jul 20 '17 at 10:38
  • you can use a struct to make an immutable with setters in c# – Ewan Jul 20 '17 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. – Bart van Ingen Schenau Jul 21 '17 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. – Bart van Ingen Schenau Jul 21 '17 at 14:31

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