デザインパターンなど暗記するな、要はインターフェイスの使いどころだ

デザインパターンが覚えられない？

読んでわかった気になるが、使うことなくそのうち忘れ、読み返してはまた忘れる。
ええ、私もです。

大丈夫、心配は無用です。
プログラマーの生産性は、知っている GoF パターンの数で決まるわけではありません。

そのことをこれから説明していきます。
忘れるにも理由のあることがわかります。

知らないおっさんが偉そうに暴論を。

なんて思いながらも、一つのお題として冷やかし半分で読めば、意外に成長のヒントが得られるかもしれません。

さて。
リファクタリングをしていて、あるインターフェイスを導入することで一気にコードが整理されていくことがあります。
そうした経験を重ねることで確信しました。

デザインパターンを覚える必要などありません。

あえて挙げるなら、ストラテジーのエッセンスだけ、覚えるというより馴染むことができるといいでしょう。
あとはぼんやり「そんなのあったな」くらいの状態で頭に残しておき、必要なときにピンと来て調べれば十分です。

現実的なことで言うと、今どきの充実したフレームワーク環境で求められるのは、パターンの組み方より使い方です。
今どき、ソートアルゴリズムを素早く組めることを生産的なプログラマーの必要条件と考える人はいないでしょう。
同じことが、現代であればデザインパターンについて言えます。
主要なプログラミング言語を使っていれば、自然と使っているパターンも多くあります。

そもそも、なぜデザインパターンを覚えようとしたのでしょう。
名の知れたあの人も薦めるから？
プログラマーとして箔をつけたいから？
何となくスキルアップできる気がしたから？
あるいは、これくらい知ってないと恥ずかしい、というネガティブな動機から？（私）

知らずに困ったとか、あのとき知っていれば、という経験はあったでしょうか。
パターン愛好家にマウントを取られた以外で。

もともとデザインパターンは、優秀な人が時間をかけるとたどり着く解を汎用的に整理したものです。
再利用性が高いならフレームワークがサポートすべきですし、そうでないなら使える場面は限られます。
同じく迷う人のヒント、省力化にはなりますが、実務では試験のようにまんまのお題は出てきません。
丸暗記しても使いどころを間違えるだけです。
改修であれば既存コードをよく知ることも必要不可欠でしょう。

今困っていることに最適な解は、最終的には自分で見出だすしかありません。

残念ながら、パターンを覚えたくらいでコード品質や生産性が上がるほど現実は甘くない

ということですね。
知識を持っているだけでは負債です。
使いこなせて初めて、技術の効果が出ます。
使いこなせるということは、使う場を間違えない、必要な場でしか出さない、ということになります。

ブレークスルーを起こすのは適切なインターフェイスの導入です。

コード空間に広がる概念を、どういう枠でどう括るか。
これは形式的に体系化するのが難しいかもしれません。
知識ではなく、実践にもとづくセンスが求められます。

いつでもどこでも使えるような正解はありませんが、適切なインターフェイス導入の効果は絶大です。
これまでの開発経験の中で、「このインターフェイスが勝負を決めた」ということが何度かありました。
それを生み出す過程は、瞬間の思いつきだったり、丸一日かけた試行錯誤の末だったり、いろいろです。

こうしたインターフェイスの特徴として、しっくりくればくるほど、目立たない形で力を発揮します。
その枠に沿って実装していると、自然と恩恵を受けることができます。

では、それを習得するにはどうすればいいのか？

インターフェイスについては、抽象化、標準化、疎結合…いろいろと表現できると思いますが、肝となるのは「どの切り口でどこまでのクラス群を括り、どんな役割を与えるか」でしょう。
各インターフェイスの役割と適用範囲が明確になることで、独立性の高い協調関係が生まれます。

以下、コツと言うほど体系化されていませんが、実際に功を奏したポイントです。

• 命名は重要です。役割、適用範囲が決まったら、それらを名前に込めましょう。そうすることで、ブレることなく、適切なクラスで実装、適切な場で使用されることが期待できます。

• 継承関係のない（異なる成り立ちを持つ）対象も透過的に扱うことになりますので、機能にしても適用範囲にしても、あまり欲張らない方がいいです。実装には網羅性が求められますが、インターフェイスは想定された文脈において必要となる振る舞いさえサポートできれば十分です。

• なくて済むならインターフェイスはいらないです。なんとなく、とりあえず、格好いいから、皆そうしているからとインターフェイスをつけてみたところで、あとでいいことが待っているわけではありません。役に立つ場面がなければ開発効率を下げるだけですので、現実の要件やソースコードと向き合って吟味しましょう。

• リバート覚悟でいろいろ試して最適解を見つけるのも、過程はしんどいですが、いい経験になります。

否定的に書きましたが

デザインパターンの本を読むことに意味がないとは言いません。
考え方など勉強になる点は多々あります。
もちろんインターフェイスの使い方以外にも。
リファクタリングのパターンなどは、「なるほど！」と、そのまま使えるものも結構ありました。
凝縮された先人の知恵ですから、暗記せずとも、一度は味わってみるといいですね。

つまり、インターフェイスの使いどころを覚えればいいプログラマーになれる？

いいえ、逆です。
確かに、プログラマーのセンスが凝縮されている気はします。
が、それでは「デザインパターンを覚えれば」と変わりません。
日々真摯にコードと向き合っていいプログラマーになることで、インターフェイスを適切に使えるようになるのです。

なんだ、抽象的な精神論か。

デザインパターンと違ってコード例もないし。
そう思われたかもしれませんね。

そうなんです。
インターフェイスという抽象的な手法を身につけるには、具体的な How To より、抽象的に考える習慣の方が役立つのではないか。
それには、解説付きの正解を見るのでなく、解答のない問いに自分でぶつかるのが一番だ。
飛び道具はないから、日々の開発を丁寧に行うことが、結果的に最短の道だろう。
というのがこの記事の問いでした。

終わりに

ほんと偉そうでごめんなさい。
でも、嘘はついていません。

次回予告

無暗にDDDなど採用するな、要はインターフェイスの使いどころだ