0

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.

stevie
  • 225
  • 3
  • 5

1 Answers1

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.

Arseni Mourzenko
  • 137,583