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.
