Golangにおいて,DBから取得したデータを構造体に格納してその構造体を返す関数を作成することを考えた場合,
Go
1type User struct { 2 Name string 3 Age int 4} 5 6type UserDB struct { 7 db *sql.DB 8} 9 10func (u UserDB) FindUserByName(name string) (*User, error){ 11... 12}
となると思うのですが,
構造体を変更することがない場合,
戻り値はUser構造体のポインタの方が良いのでしょうか.
それともそのまま構造体を返した方が良いのでしょうか.
またその理由を教えていただきたいです.
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。

回答2件
0
質問への回答としては nobonobo さんのが適切として、僕は Go のポインタと実体をどう使い分けるかの話を。簡略化して例えば以下の様な処理を例にします。
go
1package main 2 3import ( 4 "fmt" 5) 6 7type User struct { 8 name string 9} 10 11func NewUser(name string) User { 12 return User{name: name} 13} 14 15func (u User) Name() string { 16 return u.name 17} 18 19func main() { 20 fmt.Println(NewUser("bob").Name()) 21}
このコードは現状は正しく動きます。これに対して今度は name を変更出来るメソッド SetName を足します。
go
1package main 2 3import ( 4 "fmt" 5) 6 7type User struct { 8 name string 9} 10 11func NewUser(name string) User { 12 return User{name: name} 13} 14 15func (u User) Name() string { 16 return u.name 17} 18 19func (u User) SetName(newname string) { 20 u.name = newname 21} 22 23func main() { 24 u := NewUser("bob") 25 u.SetName("john") 26 fmt.Println(u.Name()) 27}
このコードは期待通りには動きません。なぜなら Go の実体に宣言されたメソッドは呼び出し時にレシーバの値のコピーが作成されるからです。よってこのコードは bob が表示されます。nobonobo さんが仰る様に、コピーにコストがかかるのでプリミティブ(boolやintやstring)でない形のレシーバに対するメソッド宣言は一般的にポインタで作られる事が多いです。(特に理由が無ければ)
ただし以下のコードを見て下さい。以下のコードはコンパイルエラーになります。
go
1package main 2 3import ( 4 "fmt" 5) 6 7type User struct { 8 name string 9} 10 11func NewUser(name string) User { 12 return User{name: name} 13} 14 15func (u *User) Name() string { 16 return u.name 17} 18 19func (u *User) SetName(newname string) { 20 u.name = newname 21} 22 23func main() { 24 fmt.Println(NewUser("bob").Name()) 25}
これは NewUser が返す実体がまだどの変数にも割り当てられていないのでアドレスが取れなず、ポインタをレシーバにした Name が呼び出せないのです。アドレスを得る為には以下の様に修正する必要があります。
go
1func main() { 2 u := NewUser("bob") // 変数に割り当てる 3 fmt.Println(u.Name()) 4}
ただこうすると NewUser、Name の呼び出しでそれぞれでコピーが発生してしまいますね。となると結局はコピーを避ける為に以下の様にするのがコピーのコストが低い事が分かります。
go
1package main 2 3import ( 4 "fmt" 5) 6 7type User struct { 8 name string 9} 10 11func NewUser(name string) *User { 12 return &User{name: name} 13} 14 15func (u *User) Name() string { 16 return u.name 17} 18 19func (u *User) SetName(newname string) { 20 u.name = newname 21} 22 23func main() { 24 fmt.Println(NewUser("bob").Name()) 25}
例としてはフィールドが name だけですが、もっとフィールド数が多い struct で想像して貰えるとなぜコピーを避けるべきかご理解いただけると思います。
投稿2018/01/23 06:53
編集2018/01/23 06:55総合スコア5030
0
ベストアンサー
見つからなかったことを上位に伝える方法はいくつかパターンがあります。
errorで見つからなかったことを返す場合、errorの分岐が必要になる場合があります。
ポインタ型は空を表現できる利点があります。(例えば該当ユーザーが見つからなかったときの値をnilで返す
)
なので「return nil, nil」を返せば、滞りなくDBアクセスは完了し、ユーザーが見つからなかったことを上位に伝えられます。
Userを非ポインタでこのFindUserByNameの戻りを提供する場合、
見つからなかったとしても何らかのUser値を返す必要があります。
また、処理コスト面だけを解説すると、
- 戻り値がポインタの場合値の格納にヒープメモリを利用します(ポインタはスタック)。
- 戻り値が非ポインタの場合スタックを利用します。
スタックメモリ操作よりもヒープメモリ操作の方が処理コストが大きいので
質問の例ならベンチマークをとってみればわかりますが、
非ポインタのほうが早い結果になると思います。
ただし、戻り値を受け取る際に代入が発生します。
戻そうとする構造体のメモリ使用量が大きくなると
代入における値のコピーコストが
ポインタ型よりも非ポインタ型のほうが大きくなっていきます。
結論としては、
硬く変更しないような小さな値セットであれば非ポインタ型で、それ以外はポインタ型にしておくことをお勧めします。
硬く変更しないような小さな値セットの例としては
要素も増える見込みのないような以下のようなものですね。
go
1type Vec2 struct { 2 X int 3 Y int 4}
フィールドに変更が発生する可能性があればポインタ型で。
投稿2018/01/23 04:49
総合スコア3367
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。

あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/01/24 09:47