やったこと

• 第5章

memo

• p117

  • オブジェクトはそのクラスよりもそのふるまいによって定義される

• p118

  • 物理世界における美とおなじいように、アプリにおけるオブジェクトの型は、見るものの目にやどります。オブジェクトの使い手はそのクラスを気にする必要はなく、気にするべきでもない
  • 重要なのはオブジェクトが何で有るかではなく、 何をするか

• p119

  • クラスをまたいだ型を認識すること、パブリックインターフェースを ~略~ 意図をもって入念につくること

• p122

  • 心の奥底では、引数はMechanicであるとおもってしまっている
    • おもってしまっている時点で特定のクラスを期待してる
    • クラスは気にしてはいけないものなので no good

• p123

  • シーケンス図はそれが描いているコードよりも常にかんたんなものでなければならない

• p124

  • prepare メソッドは旅行の準備をすること(prepare)を望みます。その引数も旅行の準備に協力しようとやってきます。prepareが引数のその動作を単に信頼すれば、設計はより簡潔になるでしょう。

• p126

  • Prepareerと相互作用するオブジェクトに必要なのは、それがPreparerのインターフェースを実装していると信頼すること だけ

• p128

  • ポリモーフィズム

• p129

  • ダックタイプの実装は比較的簡単だが、ダックタイプが必要であることに気づくことと、そのインターフェースを抽象化することが難しい
  • 隠れたダック を認識する
    • 
    • クラスで分岐するcase文
    • kind_of?とis_a?
    • responds_to>

• p132

  • ダックを信頼する

• p135

  • 動的型付けを恐れるプログラマーは、コード内でオブジェクトのクラスを検査する傾向にある。この検査こそ、まさに動的型付けの力を削ぐものであり、ダックタイプの利用を不可能にしているのです
  • 静的型付けを信じるプログラマーは、型エラーでfailすることを理由に型検査が必要だ！っていうけど、この問題の唯一の解決策は型検査を全部とりのぞくこと

• p136

  • 静的型付けのメリット

      * コンパイラがコンパイル時に型エラーを発見してくれる
          * コンパイラが型を検査しない限り、実行時の型エラーがおこる場合
      * 可視化された型情報は文書の役割を果たしてくれる
          * 方がなければプログラマーがコードを理解できない場合
      * コンパイルされたコードは最適化され高速に動作する 
          * 最適化がないとアプリの動作がおそすぎる場合
    

  • 動的型付けのメリット
    • コードは逐次実行され動的に読み込まれるため、コンパイル/makeのサイクルがない
      • アプリ全体の開発はコンパイル・makeのサイクルがない方が拘束な場合
    • ソースコードは明示的な型情報を含まない
      • 型宣言がコードに含まれないときのほうがプログラマーにとって理解するのが簡単な場合
    • メタプログラミングより簡単
      • メタプログラミングが言語機能として必要な場合

感想

メタプログラミングRuby 読まねば