Is defining get/set methods for every field overkill?

[Andrey Zherikov]

On Saturday, 19 November 2022 at 10:17:19 UTC, []() {}() wrote:
> On Saturday, 19 November 2022 at 09:51:09 UTC, []() {}() wrote:
>> ...
>> no. in C# it breaks ABI. that is why its not acceptable in my 
>> team.
>>
>
> of course that's not the reason we don't use public member 
> variables in classes.
>
> the reason we don't use them, is because (1) we always 
> anticpiate change including the need to implement (and change) 
> business rules associated with the objects data (using 
> setter/getters), and (2) we always prioritise the stability of 
> the public interface of a class at the time of design.
>
> if neither of those are your concern, in production-level code, 
> I'd be really surprised (and shocked).

We don't use public members either in most cases - we use them in 
simple structs. We have teams that do care and prioritize 
stability of public interface because they ship their libraries 
to end-users. Other teams care much less because all their users 
are internal so they can fix whatever they break.

Regarding ABI compatibility: it's usually driven by what 
dependencies your software has. In your case (as far as I got) 
you ship .dll that is used by already deployed software so your 
library must be ABI compatible with it. In our case, our software 
has only system-level dependencies like C runtime, WinSocks so we 
don't have such a thing as ABI incompatibility between different 
parts of our software but we care about system-level ABI.