Return an unexported type from a function

2020-07-01 10:49发布

Is it considered bad style to return an unexported type from an exported function?
When I've used it, I mostly find it just creates problems.

A better question might be: when is it a good idea to return an unexported type from an exported function.

标签: go
2条回答
ゆ 、 Hurt°
2楼-- · 2020-07-01 11:29

Golang's linters return a warning when you return an unexported type, so I'd say though it's technically possible it's also to be discouraged. 1

One reason is that some code that receives the unexported type cannot utilise it for various "signatures" (eg: types, funcs), without typing it as an interface (eg: interface{} or otherwise)

eg:

package people
type me string
func NewMe() me {
    return "me"
}

// in main.go
package main

type eff struct {
    m *people.me  // <-- cant do this
}

func main() {
   var m people.me // <-- cant do this
   m2 := people.NewMe() // can do this
}
查看更多
Animai°情兽
3楼-- · 2020-07-01 11:40

I would say there's nothing wrong with returning an unexported variable from an exported function. That's what an accessor is by definition.

That said, I would only do that in the case where there was some logic that needed to occur every time the unexported variable needed to be accessed.

EDIT: I hope I understand your clarified question.

If you have an unexported type user struct{} and you return it with NewUser(), would that fit your use case? If so, then that is a factory design pattern and is useful in Go if you do not want a 3rd party developer to directly create a user type object. That way, your "constructor" or "factory" is the only place to get new instances.

So, is it "bad style"? I'd say it depends on what challenge needs to be overcome.

查看更多
登录 后发表回答