> If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it
I'm not going to completely dismiss the such a practice may be plain old cargo-culting...
But as devils-advocate, properties are implemented as methods/functions, and as such (under the hood) accessed through a vtable.
This means they can be overridden in derived (generated) classes, which can then implement things like change-detection and other stuff which may be of use for a data-access/persistence class. And these derived classes can be returned in place, without the calling code knowing nothing about it.
> They make explicit reference to an objects internal fields
Not really. A property is supposed to be a public API, and definitely not "internal".
I'm not going to completely dismiss the such a practice may be plain old cargo-culting...
But as devils-advocate, properties are implemented as methods/functions, and as such (under the hood) accessed through a vtable.
This means they can be overridden in derived (generated) classes, which can then implement things like change-detection and other stuff which may be of use for a data-access/persistence class. And these derived classes can be returned in place, without the calling code knowing nothing about it.
> They make explicit reference to an objects internal fields
Not really. A property is supposed to be a public API, and definitely not "internal".