きみは Generics がとくいなフレンズなんだね，または「制約は構造を生む」

公理によって与えられる暗黙の制約。この制約が集合の要素同士をしっかり結びつける。単純にしばるのではない、相互に秩序ある関係を結ぶ。言い換えれば――公理によって与えられる制約が構造を生み出しているのだ

今回は戯れ言モードなので「プログラミング言語 Go」ではなくこちらで書いてみる。 コードは1行も書かないのでご安心を（笑）

• Big Sky :: golang と Generics と私
• golang と Generics と吾 - Qiita
• Java の Generics にもの思い - Qiita

私は出自が組込みエンジニアで（今は何でも屋），アセンブラや C/C++ から始まり Java などの制御に向いていると言われる言語を遍歴している（PHP を機器制御に使うとかいうこともやったが）。 Go 言語もその流れから興味を持っているが，あいにく私が住んでいる地方都市で Go 言語の出番はまだない。

そういう経歴を持つ私から見て Go 言語が特異だと思ったのは以下の2点である。

1. 例外処理がない
2. 明示的なクラス定義構文がない

私だけでなく C++ や Java などから来た人は大抵これで面食らうらしい。

このうち1番目については「プログラミング言語 Go」で記事にしたので割愛する。

さて，2番目の「明示的なクラス定義構文がない」について。

そもそも「クラス」とはなにか。 クラスとは以下の要素をひとまとめの「モノ（object）」として定義したものである。

• 名前（必ず1個）
• 属性（0個以上）
• 操作（0個以上）

Go 言語では明示的なクラス定義構文がない代わりに type と struct，およびメソッド・レシーバを組み合わせることでクラスの要素である名前，属性，操作を定義できる。

そしてクラス定義で重要なのは「クラス間の関係」を定義することである。 クラス間の関係としては大雑把に以下の2つがある。

1. 汎化・特化（継承 等）
2. 関連（集約，依存 等）

このうち2番目の関連は定義しやすい。 あるクラスの属性として別のクラスを定義するか，操作によって関連付けるかすればいいからだ。 問題は1番目の汎化・特化をどうやって定義するかである。

Go 言語の場合は interface を使った「構造的部分型（structural subtyping）¹」を採用した。 構造的部分型とはクラスの振る舞いに注目してクラス間の汎化・特化関係を帰納法的に定義することである。 例を挙げると，それが「にゃーん」と鳴くのなら机器猫だろうが猫耳メイドだろうがサーバルキャットだろうが全部「猫」である，ということだ。

クラス間の関係を定義するのは意外に大変である。 皆さんは「クラス設計」をどのように行っているだろうか。 まずは具体的なクラスを列挙していき，それらの関係を考察していくのではないだろうか（「ユーザ」や「管理者」を定義するのに 動物→人間→… と考えていく人はいないだろう）。 考察する過程で（クラスとクラスを繋ぐ）不可視のクラスを発見したり複数のクラスがひとつの概念で括れることに気づいたりすることもある。 つまり設計する過程では「具象→抽象」へと遡っていく。

一方，実装する際には， C++ や Java では最初にテンプレート・クラスやインタフェース・クラスを作ってからインプリメント・クラスに落とし込む。

たとえば，最初に「猫」という抽象クラスを作っておいて，それを継承する形で机器猫や猫耳メイドやサーバルキャットといった具体的なクラスを実装していく。 つまり「抽象→具象」へと作業していくわけだ。 そしてその過程において Generics² は，ほとんど必須と言えるほど利用価値の高い機能と言える。

これが Go 言語による実装ではひっくり返る。 たとえば，最初に机器猫や猫耳メイドやサーバルキャットといった具体的なクラスを作っていって「これってみんな『にゃーん』って鳴くじゃん」と気がつけば後付けで「猫」という抽象クラスを実装できるのである。

どういうことかというと， Go 言語においては設計と実装を同時進行で「具象→抽象」へと考察していくことができる，ということである。 このような思考過程においては Generics の有無はさして重要ではなくなる。 だって具象化されたオブジェクトから作り始めるのだから。

「抽象→具象」へと実装する人にとっては Generics のない Go 言語はとてもまだるこしく見えるかもしれない。 「なんで Generics がねーんだよ。いちいち全部書かせる気か。このポンコツ言語が！」となること請け合いである。 しかし一度構造的部分型に慣れた人にとっては抽象クラスから書かなければならない C++ や Java こそが面倒くさい。 何故なら，脳内では「具象→抽象」で思考していくのに実際に書くときには「考え終わらないと書けない³」からである。 Go 言語なら「考えながら書ける」のに。

これはどちらが正しいかという問題ではない。

たとえばウォータフォール型⁴ の開発スタイルでは実装を開始するまでに設計が終わることが（建前上は）保証されているため「抽象→具象」へと書き進めることが容易な言語が向いている。 一方，要件が絶えず変わったり実験的な製品の場合は設計が終わるまで待っていられないため Go 言語のような言語が向いてるかもしれない。 まぁ設計と実装を同時にやろうとするとリファクタリングが頻繁に発生するのでコピペ・プログラマにはキツい作業になるかもしれないが。

個人的には「プログラマは要件定義の段階から参加してコードを書くべき」と思ってるので，これを容易にするであろう Go 言語には注目している。

2018-10-11 追記

“Go 2 Draft Designs” において将来バージョンにおける Generics 対応の言及がある。

• Go 2のgenerics/contract簡易まとめ
• 次期 Go 言語で導入される（かもしれない）総称型について予習する

ブックマーク

• Why Everyone Hates Go · npf.io
  • [翻訳]なんでGoってみんなに嫌われてるの？ - Qiita
• Why Go? | Dave Cheney
  • [翻訳] Why Go? - Qiita
• Go 言語における「オブジェクト」
• JavaScriptで継承を使わないプログラミングスタイル - JavaScript勉強会 : オブジェクト指向設計について上手くまとめている
• Go にジェネリクスがなくても構わない人たちに対する批判について - methaneのブログ

参考図書