達人プログラマーを読んだメモ　23. 表明プログラミング

会社で購入してもらった「達人プログラマー」を読んでいます。これが評判通りなかなか勉強になりますので、
個人的な備忘録として残します。
内容はそこまで新鮮なものではないのですが、ソフトウェア開発で常識とされていることが、「何故」常識と言われているのかといた理由や説明がしっかりしているので、改めて理解する分に最適だと思います。

以下、達人プログラマーを読んだメモ&個人的見解です。
（興味がある節から読んでいるので、順不同です）

23. 表明プログラミング

要点

• プログラムにおいて、「そんなことは起こりえない」なんてことはありえない。
  

  • 「このコードは今後３０年も使われるはずがないから年は２桁で十分だ」
  • 「count が負になるはずがない」

• 「起こるはずがない 」と思っていることがあれば、「表明」を用いて保証すべし
  • いわゆる Assertion マクロで、モジュールに記述する
• コンパイル時に表明がオフされる場合があるので、表明内では決して副作用が起きないようにすべし（例えばC言語の assert マクロは、リリースコンパイルでは呼び飛ばされる）
• しかし、本番環境では、テスト環境上では発生しないことが起きえるので、出来る限り表明はオンにしておくことをオススメする

解説および個人的な見解

プログラミングにおける「表明」は、いろいろな著名な書籍において取り上げられています。

• オブジェクト指向入門の「契約による設計」の章にも、たしか「表明＝そのモジュールとの契約事項」というような説明がされていたと思います。
• エリックエヴァンスのドメイン駆動設計でも「表明」の章にも、「クラスの事前条件として表明を使用すべき」と記述されています

個人的な見解としては、「防御的プログラミング」と相対するものだと捉えています。（この「達人プログラマー」の本では、ある意味「防御的プログラミング」の機能を期待するものとして表明が紹介されていますが）
モジュールの入り口に Assertion マクロを入れ込むことで引数チェックと同等の振る舞いになるので、結果的に防御的プログラミングと同じように見えますが、目的が違います。

• 防御的プログラミング・・・対象のモジュールにどんな入力が与えられるか保証できないので、どんな入力に対しても対応できるように防御するコードを記述しよう
• 契約による設計（表明）・・・対象のモジュールの事前条件を定義し、その条件を表明としてコードに記述しよう

プログラムの動作は結果的に同じかもしれませんが、表明のほうが、コードに「条件」という意思を表現できる分、個人的には優れていると考えています。