Struct members, hide or export?

[Jay Guo]

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

[snmed]

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

[Manlio Perillo]

On Thursday, August 9, 2018 at 9:50:55 AM UTC+2, Jay G wrote:

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

The words "internal usage" and "users accessing the api" are in contradictions.

For internal usage I assume a package inside an "internal" directory.

> [...]

Manlio 

[Jay G]

On Thu, Aug 9, 2018 at 8:14 PM Manlio Perillo <manlio....@gmail.com> wrote:
>
>
>
> On Thursday, August 9, 2018 at 9:50:55 AM UTC+2, Jay G wrote:
>>
>> 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
>>
>
> The words "internal usage" and "users accessing the api" are in contradictions.

users = other pkgs within project using this lib
internal = not intended to be used by other projects

>
> For internal usage I assume a package inside an "internal" directory.

yes

thanks!
- J
>
> > [...]
>
> Manlio
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/iZMw82G-lMo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.