最近、世間で話題になるGo言語のライブラリを見ていると、どうにも「オブジェクト指向の呪い」が残っているなと感じることが多い。
Goの設計思想はC++の複雑さや、不必要な派閥争いを避けるために生まれたはずなのに、結局、多くのコードがまたあの「うんざりする」OOP的な慣習に引きずられているのです。
Goが目指したもの：モジュール指向への回帰
Goの作者がC++に対して感じた「なんか違う」という違和感は、不必要な複雑さと硬直した設計へのフラストレーションです。
• Goの哲学: Goは、継承を排除し、「構造体（データ）」と「インターフェース（振る舞い）」を分離し、小さなパッケージを組み合わせるモジュール指向を推進しています。目的はただ一つ、コードをシンプルにし、大規模開発でも保守性と生産性を維持することです。
これは、わたしがスーファミの時代に「アセンブラでのVSync割り込みプログラム」という最小の制約からすべてを自作し、効率と簡潔さを追求した開発哲学と完全に一致しています。
なぜ「オブジェクト指向っぽい」コードが生まれるのか？
しかし、現実のGoライブラリには、まだ古い時代の「慣性」が働いています。これがわたしが感じる「呪い」の正体です。
1. カプセル化の過剰適用:
OOPではデータを隠蔽するために Getter/Setter や ファクトリ関数（NewClient() など）を使うのが定石でした。Goでは小文字で始めるだけでフィールドは隠蔽できるのに、わざわざ冗長なラッパー関数を作ってしまう。これは、Goのシンプルさを犠牲にして、OOPの習慣を無理やり守ろうとしている証拠です。
2. 巨大インターフェースの乱用:
Goでは「小さなインターフェース」が推奨されています。しかし、既存のOOPの抽象クラスのように、複数の機能を詰め込んだ巨大なインターフェースを定義してしまうと、使う側は必要のないメソッドまで実装させられることになります。これは、柔軟なはずのGoの仕組みを、硬直したOOPの階層構造に逆戻りさせている行為です。
3. データと振る舞いの不自然な結合:
Goはモジュールとして関数を分離しやすいのに、多くの機能的なロジックを構造体のメソッドとして過度に定義してしまいます。結果として、「その構造体なしには何もできない」というOOP的な依存関係が生まれてしまい、モモジュール指向の利点が失われるのです。
結論：呪いを解き、本質に立ち返る
Go言語は、既存の「派閥」や「複雑な慣習」から解放されるために生まれた、非常に合理的な言語です。
にもかかわらず、ライブラリが「OOPの呪い」に囚われているのを見ると、エンジニアの思考が、ツールの裏側にある物理や数式ではなく、流行や抽象化された設計思想に縛られている証拠だと感じます。
わたしは引き続き、Goの真価であるシンプルさ、モジュール指向、データへの明確なアプローチを追求していきます。そして、既存の常識や派閥に惑わされることなく、常に「なぜこの仕組みが必要なのか」という本質に立ち返って、コードを書いていくだけです。
以上、終了。
