In Java/C# land refactoring tools even give one-click access to "create me some setters/getters".
This is not to say that abstracting access with functions has no place, but if all they do is get/set the value, they are unnecessary.
Six months later, you discover that you, in fact, do need to do something besides getting/setting the value.
If you created a getter/setter, you could just change its code. If you, instead, had raw access to the field, you now need to update every single instance of client code that called your getter/setter.
Most of the time, your compiler/VM can optimize the getter/setter call away, and a bunch of trivial get/set logic isn't exactly the worst source of cognitive overhead.
Write the best possible code needed today. Anything else is premature abstraction.
I do get the "what if" temptation, I just think it should be actively resisted.
A helpful (to me) metaphor is that you're paying for an option. (In the finance sense, not the type system sense.) Sometimes it's worth buying an option, sometimes it's not, but don't think it's free.
It's certainly wise to subscribe an insurance for your house, but for every single drinking glass you own...?
If it's a tea set you inherited from your great-grand-mother, when you break it the insurance won't un-break it. If your property suddenly needs to be more than a property, chances are that this change will break the LSP or trigger a larger redesign anyway.
Auto-properties in C# are one line of code, same as fields, and the getter/setter methods should always be inlined which turn them into field accesses anyway. So I'm not sure how that would affect compile times or lead to slower code in anything but some pathological use case. Or DEBUG, but at that point all performance bets are off.
(Technically Microsoft can get worse performance on properties vs. fields when using NGen - that's why they have TargetedPatchingOptOutAttribute - but that doesn't apply to regular, non-Framework assemblies.)
As for code bloat `public int SomeValue { get; private set; } = 6;` encapsulates a publically read-only/privately mutable property with a default value quite concisely...
Wait, wait, since when can you put the default assignment right there on the same line? Go ahead, say since always... I dare you.
Edit: Apparently this came in C# 6.0 (July, 2015). Ok, now I don't feel so bad. :-)
On a separate note, C# might not sexy or even that popular, but I really enjoy coding in it, and the continuing evolution of the syntax is a joy.
Though I doubt this makes a ton of real world impact, performance wise. Stripping names would do more to shrink the .Net code.
And if you wanted a publically read-only/privately mutable value without properties you'd have to write ... a field and one method. Possibly two methods if you wanted some shared validation code everywhere you assign the field.
Like I said, in practice, it's the same. If you have some case where three vs. two members makes a difference you're in pathological case territory.
public double Area
{
get { return Width * Height; }
set
{
Width = Math.Sqrt(value);
Height = Width;
}
}
public double Area => Width * Height;Have they introducted willSet and didSet too?
Neat stuff, i may try the language out in a future project on windows.
[1] https://msdn.microsoft.com/en-us/library/system.componentmod...
[2] https://msdn.microsoft.com/en-us/library/system.componentmod...
For interfaces, you can only invoke methods, so getters/setters are required.
I really like Go, but on the const/mutability front, it does no better than C, unfortunately.
In Go it has real runtime cost as unlike C/C++ (you have an optimizing compiler) [1] , and in Java/C# you have the JIT which will optimize out your method calls over enough time.
A lot of FP languages are perfectly fine building Abstractions without getters/setters. But in OOP land people believe this is a requirement. 2/4 OOP _principles_ encapsulation and inheritance have aged like dirty sweat socks in a hot gym locker.
[1] https://klaig.blogspot.be/2012/09/the-go-language-is-faster-...
Note that Go's compiler does do function inlining, so it might be possible to encapsulate your data without runtime costs. With that said, you certainly don't have the flexibility that you have in C/C++/Rust.
Of course I agree that blindly adding getters/setters everywhere is bad juju. But to say encapsulation isn't useful is a step too far. Instead of thinking in terms of getters/setters, I'd rather think in terms of invariants on your data. If you have invariants you want to protect, then encapsulation is one possible tool you can use to protect them.
Unless you're building an API.
So look at my comment as a refinement on that idea?