4 ms·

Encapsulation isn't _that_ useful. 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

Encapsulation isn't _that_ useful. 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-than-computer.html https://klaig.blogspot.be/2012/09/the-go-language-is-faster-...

burntsushi 9y ago
Take a look at the `time.Time` struct. It has a couple fields. What are the trade offs of making those fields public? (I contend that encapsulation is supremely useful, and the time package is a good exemplar.) 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.
- kartickv 9y ago
  He didn't say encapsulation is not useful. He said it's not that useful. In other words, blindly encapsulating everything because that's supposed to be the right way is overkill. Unless you're building an API.
  - burntsushi 9y ago
    > He didn't say encapsulation is not useful. He said it's not that useful. So look at my comment as a refinement on that idea?
nine_k 9y ago
This is because most FP languages embrace immutability, so setters are absent by design, and getters are not needed. Any computation goes to proper functions, not "getters". Absence of virtual methods also helps: there is no point in having a getter (or a setter) if nobody would override it.

burntsushi 9y ago

Take a look at the `time.Time` struct. It has a couple fields. What are the trade offs of making those fields public? (I contend that encapsulation is supremely useful, and the time package is a good exemplar.) 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.

kartickv 9y ago
He didn't say encapsulation is not useful. He said it's not that useful. In other words, blindly encapsulating everything because that's supposed to be the right way is overkill. Unless you're building an API.
- burntsushi 9y ago
  > He didn't say encapsulation is not useful. He said it's not that useful. So look at my comment as a refinement on that idea?

nine_k 9y ago

This is because most FP languages embrace immutability, so setters are absent by design, and getters are not needed. Any computation goes to proper functions, not "getters". Absence of virtual methods also helps: there is no point in having a getter (or a setter) if nobody would override it.