Goのシンプルさについて
- 1. Goのシンプルさについて
- 2. 自己紹介 twitter : pospome blog ：pospomeのプログラミング日記 職種 : サーバサイドエンジニア 興味 : クラス設計全般, DDD アイコン：羊じゃなくてポメラニアンです
- 4. ・package private ・コンストラクタ ・struct に static な method
- 5. ・package private ・コンストラクタ ・struct に static な method
- 6. 自分が触ったオブジェクト指向言語には アクセス修飾子として以下が用意されていた モジュールレベルの public, private クラスレベルの public, protected, private
- 8. 仮に 1つのモジュールに大量のクラスを突っ込んでも 触られたくないものをクラスレベルで隠すことができるので ある程度の秩序は保たれる 最悪モジュールの依存関係、粒度は気にしなくても なんとかなる
- 11. 仮に 1つのパッケージ内に大量の struct を突っ込むと 全てが触り放題になってしまう 触られたくないものが存在する場合、 パッケージを分けて package private にする必要がある
- 12. つまり、Go では パッケージレベルのアクセス修飾子だけ考えればいい パッケージの循環参照が禁止なこともあり、 パッケージレベルで 粒度、公開範囲、依存方向を考えるべき struct ベースで考えてもこれらは解決できない struct は保持する値と振る舞いの管理だけ考えればいい パッケージと struct で妙な責務の分離ができている
- 14. ・package private ・コンストラクタ ・struct に static な method
- 15. Go にはコンストラクタがない NewXxxx() という function が コンストラクタのような役割を担っている 実質 static な factory method みたいな実装になる
- 16. 個人的にはコンストラクタよりも 実装パターンとしての static な factory method が好き 「どんなオブジェクトを生成するのか」 をメソッド名で表現できるから
- 18. ・package private ・コンストラクタ ・struct に static な method
- 19. Go では struct に static な method を持たせることができない 最初は違和感しかなかったし、 static method 欲しかったので、 無理やりそれっぽい実装したこともあった
- 20. ただ、最初に説明したとおり、 Go はパッケージを中心に考えた方がいい気がする 無理やり struct に static method を持たせることに 違和感があるのも事実
- 22. シンプルな点 struct に static method は生やせないので function で実装する
- 23. まとめ
- 24. ・package private しかない ・コンストラクタはない ・struct に static method はない 削ることによってシンプルになっている
- 28. おわり