1. 2013-08
1.1. プログラムの複雑さ
1.1.1. 原因
1.1.1.1. ではない
1.1.1.1.1. 副作用
1.1.1.2. である
1.1.1.2.1. 可変性
1.1.2. 解決策
1.1.2.1. 変数への再代入不可 (単一代入)
1.1.2.2. オブジェクト状態の変更不可
2. 2013-07
2.1. 圏論とかモナドなんて簡単だからscalaを使って説明してみた - だらだらしてたいなぁ
2.2. Haskell-モナド CapmNetwork
2.2.1. モナドとは制御構造を導入するための「データに付ける付加情報」である
2.2.2. モナドはデザインパターンの一種と考えることができる
2.3. モナドとはプログラマブルセミコロンである
2.3.1. 「モナドについて」(スライド)
2.4. jQueryはすごくわかりやすいモナドの例になっている
2.4.1. jQueryのAPIもモナドになっている
2.4.2. モナドとは本当にやりたいことのみを書き並べ、各々のやりたいことの間を繋ぐ裏方作業をコード上から消し去る設計
2.4.2.1. モナド: お前はすでに知っている
2.4.2.1.1. スライド
2.4.2.1.2. Web
2.5. 関数型言語脳の常識 (…かどうかはわからない) fold 編
2.5.1. 関数脳では
2.5.1.1. 共通した処理を見つけたら、まず関数化する
2.5.1.2. 同じ関数の呼び出しは引数をリストにして一気に処理する
2.6. 関数内やコレクション関数の中でlambdaで関数定義
2.6.1. サブ関数の呼び出し関係が明確になる(その場で使うことがわかる)
2.7. 刺激を求める技術者に捧げるScala講座 - 第7回 関数脳のつくり方 First Season：ITpro
2.7.1. 変数はオブジェクト内部でのみ変更される
2.7.2. 他のクラスで変数が必要なときはオブジェクトごと渡す
2.7.3. 疑問
2.7.3.1. 他のクラスに渡したオブジェクトが操作され、内部変数が書き換わったら、グローバル変数と同じではないか?
3. 関数型について
3.1. 関数型の利点
3.1.1. テスト容易性
3.1.1.1. 関数型の利点は同じ引数で呼び出すと常に同じ結果が返ってくる
3.2. 副作用を減らす
3.2.1. World を受け取って 変化後の World を返す
3.2.1.1. Concurrent Clean の方法
3.2.1.1.1. 一意型
3.2.1.1.2. 処理後は処理前の値は使わない
3.2.1.2. JavaScriptでやる案
3.2.1.2.1. document を受け取り, 処理し, document を返す
3.3. 関数型の真髄
3.3.1. イミュータブルであること
3.3.1.1. 手続き型でイミュータブルで作れるか？
3.3.2. 参照透明性
3.3.2.1. 同じ引数で同じ結果が返ってくる
3.3.2.2. 副作用がない
3.4. LISPはなぜリスト形式か
3.4.1. ラムダ算法もチャーチ数もリストと関係ない
3.4.2. Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I
3.4.2.1. この論文で参照している先行研究
3.4.2.1.1. The Logic Theory Machine
4. オブジェクト指向について
4.1. メソッド呼び出し構文の利点
4.1.1. メソッドのグループ化
4.1.1.1. a1.method1(args)
4.1.1.2. 関数型で書き換えると
4.1.1.2.1. ClassA.method1(a1, args)
4.1.1.2.2. いちいち ClassA.methodo1 や ClassB.method1 と使い分ける必要がある
4.1.2. フロー記述
4.1.2.1. a1.method1.method2 ...
4.2. メッセージパッシング
4.2.1. 大きなパッケージ間などでは有効
4.2.2. 小さいデーター間では冗長ではないか
4.3. オブジェクト指向エクササイズの「メンバー変数2つまで」の意味
4.3.1. ある 値 (オブジェクト) の 有効範囲を 狭める
4.3.2. Access で 締日の 数値 → 文字列に 変換する 処理を どこに 置くかを 考える
4.3.2.1. 他の MDB にも 入れる ことを 考えると, モジュールは 小さくする 方が よい
4.3.2.2. できれば それ 専用の モジュールに する
4.3.2.3. オブジェクト指向では 処理に 必要な 値で オブジェクトを 作り, 処理 させる
4.4. オブジェクト指向・嗜好・試行・至高・歯垢 | ログ速＠まとめ表示
4.4.1. >>15 プリンタを例とした抽象化の説明
4.4.1.1. どんなプリンタでも同じダイアログから印刷できる
4.4.2. >>22 getter/setterの有用性の説明
4.4.2.1. 値チェックやアクセスログ、インプリメンテーション変更
4.4.3. >>47 再利用性より生産性のために使った方がよい
4.4.4. >>54 デザインパターンはOOによる恩恵
4.4.4.1. 頭のいい人の手法を再利用できる
4.4.4.2. 抽象化された部分を再利用し、具体化は後回しにできる
4.4.5. >>126 OOは言語ではなく考え方
4.5. 「すべてがオブジェクト」の言語は作れるか?
4.5.1. オブジェクト指向言語ではオブジェクトはオブジェクトから構成されるか?
4.5.1.1. LISPでは関数は関数から構成される
4.5.2. 手続き型プログラミングなしにオブジェクト指向プログラミングできるか?
4.5.2.1. Smalltalkの代入はメッセージ送信か?
4.5.2.2. Smalltalkのreturn(↑)はメッセージ送信か?
4.6. メッセージ指向で考えてみる
4.6.1. 「呼び出し先のオブジェクトは物理的に離れたマシン上にある」と考える
4.6.2. Actorで考える
4.6.2.1. 戻り値を受け取るには、自分にメッセージを送ってもらう
4.7. メソッドチェーン
4.7.1. 常に新しい値を返すと関数的に綺麗に書ける
4.7.1.1. 実例
4.7.1.1.1. Ruby - 円周上のCrossing - Qiita [キータ]
5. オブジェクト指向と関数型のハイブリッドについて
5.1. うまく作るには
5.1.1. 副作用を最小限に抑える
5.1.1.1. コマンドクエリ分離原則 (Command-Query Separation: CQS)
5.1.1.1.1. Side-Effect-Free-Functions パターン
5.1.1.2. コマンドクエリ責務分離 (CQRS: Command and Query Responsibility Segregation)
5.1.1.2.1. CQS をアーキテクチャ全体に適用できるように発展させたもの
5.1.1.2.2. データーは DTO で取得する (副作用なし)
5.1.1.2.3. コマンド (ふるまい) を発行して更新する (副作用あり)
5.1.1.2.4. Aggregate Root (集約ルート)
5.1.1.2.5. 参考資料
5.1.2. 副作用を最小限に抑えるために必要なこと - じゅんいち☆かとうの技術日誌
5.1.2.1. 人間は状態を扱うためのメンタルモデルを持っている (ケント・ベック)
5.2. 相互書き換え
5.2.1. 第 1 引数をターゲットにして書き換えられる
5.2.2. method1(obj1, obj2) ⇔ obj1.method1(obj2)
5.3. まず関数化し、必要があるまでオブジェクトにしない
5.3.1. オブジェクト指向は、ある種のパターンだと考えるとよいかも
5.3.1.1. デザインパターンの前提となるパターン
5.4. 引数は必要なもののみにする
5.4.1. 切り替える必要がある部分のみ引数にする
5.4.2. シンプルになる
5.4.3. 詳細を隠せる
5.4.4. 設定ファイルから読み込む
5.5. つないで作成
5.5.1. プログラムをグラフィカルに部品をつないで作成する
5.5.1.1. JavaStudio
5.5.1.2. ASTERIA
5.5.1.3. Yahoo! Pipes
5.5.2. 関数型は作成しやすい
5.5.2.1. 相互作用がないから
5.5.2.1.1. 線はすべて単方向になる
5.5.2.2. ホワイトボードにも簡単に描ける
5.5.2.2.1. A Life in Shinjuku.: 技術者／プログラマのためのモナドと圏論 第1回 行ってきた
5.6. クラスに属さない関数
5.6.1. insertFirst(Element1, Element2)
5.6.2. Element1 と Element2 を入れ替えてもよい
5.6.3. 純粋な関数として作った方が使いやすい
6. オブジェクト指向への疑義
6.1. 「オブジェクト指向とは何か」が十人十色になる
6.2. 適切なクラス分けが難しい
6.3. オブジェクト指向は死んだ?
6.3.1. Object Oriented Programming is Dead
6.3.2. Programming Like It’s 1995
6.3.2.1. 巨大で複雑なライブラリを作るのに向いている
6.3.2.2. 普通のプログラムには大きく複雑すぎる
6.3.2.3. ほとんどのオブジェクトはデータホルダーやレコードになっている
6.3.2.4. オブジェクトを忘れると幸せになれる
6.4. オブジェクト指向プログラミングは間違いだったか?
6.4.1. Joe Armstrong博士のアドバイザ
6.4.1.1. オブジェクト指向言語はオブジェクト指向ではない
6.4.1.2. Erlangは唯一のオブジェクト指向言語である
6.4.2. Alan Kay
6.4.2.1. 「オブジェクト指向」という言葉は悪い選択だった
6.4.2.1.1. メッセージ送信の重要な考えを強調していない
6.4.2.2. メッセージだけで伝達するとスケーリングを提供する
6.4.2.3. 本当のオブジェクトは端から端まで本当のコンピュータ (RCATWD: Real Computer All The Way Down) である
6.4.2.4. 古い (間違った) オブジェクト指向はデーターをプロシージャに行き着く
7. Erlang
7.1. すべて関数
7.2. 変数への代入(バインド)は1度だけ
7.2.1. 更新できない
7.3. ループ構文なし
7.3.1. 再帰で書く
7.4. 状態を持つには関数をアクター化する
7.5. アクターは値を返さない
7.6. パターンマッチングで変数にバインドする
7.7. リスト、タプルを使う
7.8. 高階関数
7.8.1. クロージャも作成可能
7.8.1.1. ただし環境内の値の書き換えはできない
7.9. Erlangで作ると構成に悩む必要がない
7.9.1. オブジェクト指向ではクラスの切り分けで悩むことが多い
7.10. Erlangでプログラミングしてみての知見
7.10.1. 同期して値を返すものは関数にする
7.10.2. 非同期に動作するものだけプロセス(オブジェクト)にする
7.10.3. 変数を書き替えない
7.10.3.1. 必要なら引数にして再帰する