Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

オブジェクト指向と関数型 by Mind Map: オブジェクト指向と関数型
0.0 stars - reviews range from 0 to 5

オブジェクト指向と関数型

2013-08

プログラムの複雑さ

原因, ではない, 副作用, である, 可変性, 変数, オブジェクト

解決策, 変数への再代入不可 (単一代入), オブジェクト状態の変更不可

2013-07

圏論とかモナドなんて簡単だからscalaを使って説明してみた - だらだらしてたいなぁ

Haskell-モナド CapmNetwork

モナドとは制御構造を導入するための「データに付ける付加情報」である

モナドはデザインパターンの一種と考えることができる

モナドとはプログラマブルセミコロンである

「モナドについて」(スライド)

jQueryはすごくわかりやすいモナドの例になっている

jQueryのAPIもモナドになっている

モナドとは本当にやりたいことのみを書き並べ、各々のやりたいことの間を繋ぐ裏方作業をコード上から消し去る設計, モナド: お前はすでに知っている, スライド, Web

関数型言語脳の常識 (…かどうかはわからない) fold 編

関数脳では, 共通した処理を見つけたら、まず関数化する, 同じ関数の呼び出しは引数をリストにして一気に処理する

関数内やコレクション関数の中でlambdaで関数定義

サブ関数の呼び出し関係が明確になる(その場で使うことがわかる)

刺激を求める技術者に捧げるScala講座 - 第7回 関数脳のつくり方 First Season:ITpro

変数はオブジェクト内部でのみ変更される

他のクラスで変数が必要なときはオブジェクトごと渡す

疑問, 他のクラスに渡したオブジェクトが操作され、内部変数が書き換わったら、グローバル変数と同じではないか?

関数型について

関数型の利点

テスト容易性, 関数型の利点は同じ引数で呼び出すと常に同じ結果が返ってくる

副作用を減らす

World を受け取って 変化後の World を返す, Concurrent Clean の方法, 一意型, *World -> *World, 変更後に変更前のデータを使わないことを保証, Cleanの一意性型付け - masakiの雑記帳, 処理後は処理前の値は使わない, 普通のオブジェクトと同じ, JavaScriptでやる案, document を受け取り, 処理し, document を返す, c(b(a(document))), モナドを使って連結, M(document).bind(a).bind(b).bind(c), オブジェクト指向との類似性, a, b, c は document のメソッドにできる, 常に修正後の document に対して処理をすることになる, 関数型のテスト容易性はオブジェクト指向ではどうなるか?, 同じ入力を与えられたら, 関数は同じ結果を返す, 同じオブジェクトを与えられたら (入力) メソッドは同じ結果 (オブジェクトの状態) を返す (出力), この考え方 (World) ではオブジェクト指向も関数型も同じ

関数型の真髄

イミュータブルであること, 手続き型でイミュータブルで作れるか?

参照透明性, 同じ引数で同じ結果が返ってくる, 副作用がない

LISPはなぜリスト形式か

ラムダ算法もチャーチ数もリストと関係ない

Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I, この論文で参照している先行研究, The Logic Theory Machine, そこで提唱されているプログラミング言語IPL-V, Information Processing Language, IPL-V Programmers’ Reference Manual, 名前,データー,次のセルという形式でプログラムとデーターを配置して実行する, マッカーシーはこれを括弧を使って書き下せるようにしたのだと推測, ただし入れ子はできず、一直線に単純な値を並べるだけ

オブジェクト指向について

メソッド呼び出し構文の利点

メソッドのグループ化, a1.method1(args), 関数型で書き換えると, ClassA.method1(a1, args), いちいち ClassA.methodo1 や ClassB.method1 と使い分ける必要がある, ClassA と付けるのが煩雑, Haskell の型クラスなら method1(ClassA) と method1(ClassB) で実装を変えられる

フロー記述, a1.method1.method2 ...

メッセージパッシング

大きなパッケージ間などでは有効

小さいデーター間では冗長ではないか

オブジェクト指向エクササイズの「メンバー変数2つまで」の意味

ある 値 (オブジェクト) の 有効範囲を 狭める

Access で 締日の 数値 → 文字列に 変換する 処理を どこに 置くかを 考える, 他の MDB にも 入れる ことを 考えると, モジュールは 小さくする 方が よい, できれば それ 専用の モジュールに する, オブジェクト指向では 処理に 必要な 値で オブジェクトを 作り, 処理 させる

オブジェクト指向・嗜好・試行・至高・歯垢 | ログ速@まとめ表示

>>15 プリンタを例とした抽象化の説明, どんなプリンタでも同じダイアログから印刷できる

>>22 getter/setterの有用性の説明, 値チェックやアクセスログ、インプリメンテーション変更

>>47 再利用性より生産性のために使った方がよい

>>54 デザインパターンはOOによる恩恵, 頭のいい人の手法を再利用できる, 抽象化された部分を再利用し、具体化は後回しにできる

>>126 OOは言語ではなく考え方

「すべてがオブジェクト」の言語は作れるか?

オブジェクト指向言語ではオブジェクトはオブジェクトから構成されるか?, LISPでは関数は関数から構成される

手続き型プログラミングなしにオブジェクト指向プログラミングできるか?, Smalltalkの代入はメッセージ送信か?, Smalltalkのreturn(↑)はメッセージ送信か?

メッセージ指向で考えてみる

「呼び出し先のオブジェクトは物理的に離れたマシン上にある」と考える

Actorで考える, 戻り値を受け取るには、自分にメッセージを送ってもらう

メソッドチェーン

常に新しい値を返すと関数的に綺麗に書ける, 実例, Ruby - 円周上のCrossing - Qiita [キータ]

オブジェクト指向と関数型のハイブリッドについて

うまく作るには

副作用を最小限に抑える, コマンドクエリ分離原則 (Command-Query Separation: CQS), Side-Effect-Free-Functions パターン, ロジック部を副作用のない関数として作る, 状態を変化させる操作 (コマンド) を最小限にする, 複雑なロジックは ValueObject に持たせるように分割する, 副作用のないことを示せる, コマンドクエリ責務分離 (CQRS: Command and Query Responsibility Segregation), CQS をアーキテクチャ全体に適用できるように発展させたもの, データーは DTO で取得する (副作用なし), 画面, レポート, 他システム, コマンド (ふるまい) を発行して更新する (副作用あり), コマンド, DSL になる, コマンドはドメインオブジェクトのメソッドではなく, より上位のもの, 他の情報を参照し, イベントを発行する (または、しない), イベント, コマンドから発行される, 他の情報を参照せず, リポジトリを書き換える, イベント = 状態変化, 保存できる, Aggregate Root (集約ルート), 役割, 相互に参照を持たないデーターを集約して提供する, 例, DB 中では ID フィールドで関連しているオブジェクトを実体化してまとめて提供する, リポジトリから参照を取得できる唯一のオブジェクト, 参考資料, Domain-Driven Design in an Evolving Architecture, 参考資料, Greg Young流CQRS - Mark Nijhof - Digital Romanticism, CQRS Documents by Greg Young (PDF), MSDN マガジン: Windows Azure 開発 - Windows Azure での CQRS

副作用を最小限に抑えるために必要なこと - じゅんいち☆かとうの技術日誌, 人間は状態を扱うためのメンタルモデルを持っている (ケント・ベック)

相互書き換え

第 1 引数をターゲットにして書き換えられる

method1(obj1, obj2) ⇔ obj1.method1(obj2)

まず関数化し、必要があるまでオブジェクトにしない

オブジェクト指向は、ある種のパターンだと考えるとよいかも, デザインパターンの前提となるパターン

引数は必要なもののみにする

切り替える必要がある部分のみ引数にする

シンプルになる

詳細を隠せる

設定ファイルから読み込む

つないで作成

プログラムをグラフィカルに部品をつないで作成する, JavaStudio, ASTERIA, Yahoo! Pipes

関数型は作成しやすい, 相互作用がないから, 線はすべて単方向になる, ホワイトボードにも簡単に描ける, A Life in Shinjuku.: 技術者/プログラマのためのモナドと圏論 第1回 行ってきた

クラスに属さない関数

insertFirst(Element1, Element2)

Element1 と Element2 を入れ替えてもよい

純粋な関数として作った方が使いやすい

オブジェクト指向への疑義

「オブジェクト指向とは何か」が十人十色になる

適切なクラス分けが難しい

オブジェクト指向は死んだ?

Object Oriented Programming is Dead

Programming Like It’s 1995, 巨大で複雑なライブラリを作るのに向いている, 普通のプログラムには大きく複雑すぎる, ほとんどのオブジェクトはデータホルダーやレコードになっている, オブジェクトを忘れると幸せになれる

オブジェクト指向プログラミングは間違いだったか?

Joe Armstrong博士のアドバイザ, オブジェクト指向言語はオブジェクト指向ではない, Erlangは唯一のオブジェクト指向言語である

Alan Kay, 「オブジェクト指向」という言葉は悪い選択だった, メッセージ送信の重要な考えを強調していない, メッセージだけで伝達するとスケーリングを提供する, 本当のオブジェクトは端から端まで本当のコンピュータ (RCATWD: Real Computer All The Way Down) である, 古い (間違った) オブジェクト指向はデーターをプロシージャに行き着く

Erlang

すべて関数

変数への代入(バインド)は1度だけ

更新できない

ループ構文なし

再帰で書く

状態を持つには関数をアクター化する

アクターは値を返さない

パターンマッチングで変数にバインドする

リスト、タプルを使う

高階関数

クロージャも作成可能, ただし環境内の値の書き換えはできない

Erlangで作ると構成に悩む必要がない

オブジェクト指向ではクラスの切り分けで悩むことが多い

Erlangでプログラミングしてみての知見

同期して値を返すものは関数にする

非同期に動作するものだけプロセス(オブジェクト)にする

変数を書き替えない, 必要なら引数にして再帰する