Hi
I would suggest to use the second option. If you export all possible
members, you have to care on every redesign who and how this members are
used. This makes a redesign unnecessarily tricky.
Constructor functions are a common pattern in go code and therefore you
should not flinch to use it. For testing you can append "_test" to the
package name and then your test can't see any non exportet members of your
package.
Cheers
Sandro
Am Donnerstag, 9. August 2018 09:50:55 UTC+2 schrieb Jay G:
>
> Let's say I'm writing some library for internal usage in my project,
> what's the idiomatic way to design visibility of struct members?
>
> - Option 1. export structs and members as much as possible. Only hide
> ones that need to be protected, e.g. by a lock
> - Option 2. hide as much as possible. Only export when necessary
>
> *Opt 1 makes testing easier when written in separate pkg. Also we don't
> rely on constructors to inject dependencies*
> *Opt 2 defines a clearer API, and prevent users from accessing unnecessary
> fields, which could be prone of error*
>
>
> Is constructor actually anti-pattern in Go?
>
> type Foo struct {
> A A
> B B
> }
>
>
> func main() {
> _ := &Foo{A: myA, B: myB}
> }
>
> vs
>
> type Foo struct {
> a A
> b B
> }
>
>
> func NewFoo(a A, b B) *Foo {
> return &Foo{a: a, b: b}
> }
>
>
> func main() {
> _ := NewFoo(myA, myB)
> }
>
>
> thanks a lot!
> - J
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
