はじめに

Goには明確なアーキテクチャスタイルはないです。よくあるレイヤードアーキテクチャだったりが正であるわけではないです。 また、Goの Standard Go Project Layoutは公式が発表しているものではないため注意してください。

今回はinterfaceについて触れていきます。

Go の嬉しさ

tagupoyoはGoで一番うれしいものはinterfaceだと思っています。

Goのinterfaceはメソッドを定義し、それらのメソッドを実装しているとinterfaceを満たしていることになります。

type UserRepository struct {
    //DBアクセスのフィールド
}

func (ur *UserRepository) Get(id string) (model.User ,error) {
	//取得処理
	return model.User{}, nil // 例としてダミーの戻り値
}

Client構造体はuserRepository interfaceを満たしているのが大切です。

type userRepository interface {
	Get(id string) (model.User ,error)
}

type Client struct {
    userRepository userRepository
}

func NewClient(userRepository userRepository) *Client {
    return &Client{
        userRepository: userRepository,
    }
}

func (c *Client) getUser(id string) (model.User, error) {
    return c.userRepository.Get(id)
}

 userRepository := UserRepository{}

 client := NewClient(&userRepository)
 client.getUser("1")

Goでは暗黙的にinterfaceが満たされてます。

Javaではインターフェースを明示的に実装する必要があるため、たとえClient側で不要なメソッド（例: Saveメソッド）であっても、インターフェースに定義されていれば実装が必要になる場合があります。

例えば、Client側で保存は不要なのにSaveメソッドが実装されているなど。

interface 勘所

Goの作者の1人であるRob Pike氏も以下のように発言しています。

The bigger the interface, the weaker the abstraction.

インターフェースが大きくなるほど、抽象化は弱くなります。

Don’t design with interfaces, discover them.

インターフェースを設計するのではなく、インターフェースを発見してください。

引用元The bigger the interface, the weaker the abstraction.

interfaceが大きければ大きいほど抽象が弱くなる。たとえば、以下のようなものです。

type ProductRepository interface {
    // 引数、返り値は省略
    Get()
    Update()
    All()
    Delete()
}

上記のように特定の者に特化した大きすぎるinterfaceは抽象ではなく、もはや具象クラスなのでは？とは思っています。 なので、interfaceは使用者側に持たせて適切な粒度で抽象にすべきです。 ちなみに、このようなinterfaceはJavaに大きく見られると著者は思っています。

インターフェースを設計するのではなく、インターフェースを発見してください。

interfaceは理由がない場合に使用しないほうがいいです。

interfaceを使用して、テストがしやすくなるなど明確な目的がある場合に実装してください。

たとえば、ロジックのテストがしたいのでDBは抽象に依存させるなどです。

まとめ

• interfaceはテストがしやすい。
• interfaceは良い抽象に依存する。
  • SOLID原則のDIPが満たせそうですね。
• 良いinterfaceを設計するためになんのために意識を常に持つ。

次回について

次回はフォルダ/パッケージ構成についてみていきます。

参考ページ

• 100 Go Mistakes and How to Avoid Them ー SOLID