I've been trying to decide if I should include getters/setters in business entities. A few reason I have been through to include getters/setters but those are accompanied by an anti-reason as well. Find them below:

  1. Insurance policy for type change: First it is extremely rare. Secondly, we can always add a new method for any new type.

  2. Public APIs to offer backward compatibility: Just like you can leave an extra getter/setter for backward compatibility, you can also leave an extra property to support that. But even if I am somehow wrong here, it still doesn't justify have getters/setters for specific apps.

  3. Immutability: Yes, we will need getters with private property for that. But that is a better reason for value objects than entities. Entities are mapped data and they are supposed to be created and updated. There may be cases where it will be good to have some property immutable but it still doesn't justify to always have getters/setters in entities. It only justifies to have getter for rare cases, also destroying the consistency of object where most properties are accessible directly, and one or more are accessible via getter.

So with all these reasons and their anti-reasons I am still confused if I should start writing an entity with getters/setters or without.

However, I will prefer to write an entity without getters/setters for sack for extremely good readability. An entity with a few properties all public is a lot more readable than the one with getters and setters.

I am looking forward to any solid reason to follow on this.

1 Answer 1


I used to eschew getters and setters, I would "Pah" those who put forward the reasons why they are better for the kind of reasons you suggest.

Now I use them all the time without a second thought. Not because I find I need these rare scenarios, but because I generally program in .net and:

  1. Microsoft made a tonne of stuff that only works on properties and not on fields

  2. They made a new syntax to make them easy to type.

We all know that getters and setters are academically better. Don't look for excuses not to use them, look for ways to make using them easier.

  • 1
    Can you please elaborate it a little? "getters and setters are academically better"
    – EresDev
    Mar 9, 2019 at 10:17
  • 1
    for the reasons you list, plus maybe a couple more esoteric language depdent ones. But basically you have that extra layer of abstraction
    – Ewan
    Mar 9, 2019 at 10:20
  • 2
    @EresDev Just like Ewan states: Instead of reading a field from memory you make a a call to a method. This is a fundamental difference. You can intercept a method call/change its logic, you cannot intercept reading a field (if the language does not use some special kind of access methods internally). Method calls are generally much more flexible. You can implement all kinds of logic by replacing access logic: change detection via setter interception, flyway pattern, lazy loading, mocking calls for tests...
    – chromanoid
    Mar 11, 2019 at 23:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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