「多態性」を含む日記 RSS

はてなキーワード: 多態性とは

2024-04-01

anond:20240401142256

そんな Rust OOP だけでGoogle検索した結果だけ出されても

 

Rustではtraitでインターフェース定義して、traitさえ実装してればなんでも受け入れる多態性を確保した関数実装して、

構造体に紐づいたメソッド呼び出しを中心としたコードがRustで書かれたコードの9割だと思うけど、

それがOOPじゃなくて何?

 

まさかカプセル化OOPだと思ってる感じの人?

可視管理OOPとは関係いからね?

2024-03-25

私の思うオブジェクト指向貴方の思うオブジェクト指向はなぜ違うのか

同じプログラマなのに話が通じないと思ったことはないでしょうか

どうやら私の思うオブジェクト指向貴方の思うオブジェクト指向は別のもののようだ

A君はウィキペディアを見ながら、カプセル化継承多態性だと言う

B君はC++/C#/Java等でプログラムを書くことだと言う

C君は OOPとOO は区別しろとか言ってくる

D君はこの世界のすべてはオブジェクトだと言う

E君はSOLID原則の方が大事だと言う

なぜかみんな見ている世界が違うようだ

どうしてこうなったのか

2023-11-17

あーそうかオブジェクト指向継承差分プログラミングするものだと理解してるから、異常なswitch文ができるのか

多態性って概念がないのね

function hoge(value):
  switch(value.a, value.b)
  case 1, ‘a’
    return methodA(value)
  case 1, ‘b’
    return methodB(value)
  case 2, ‘c’
    return methodC(value)
………

これでキャリア15年超えってマジかよ

死のうかな

2019-05-09

anond:20190509220857

オブジェクト指向本質なんて禅問答に近いものから教えられない。

ちなみに俺は問題の切り分けをしたときにその「切り口」をインターフェースによって規格化できて、

問題構成する部品を交換可能になるるあたりに本質があるのではないかと思う。

 

まあそれはどうでもいいとして、プログラミング言語におけるオブジェクト指向という機能説明なら、普通にできるでしょ。

データとそのデータに対する操作をひとまとめにしたものオブジェクトです的な。

あと具体的にいけ。

多態性は犬とネコワンニャーさせるのではなく、テキストボックスボタンでそれぞれFocusメソッドを呼び出す説明をせよ。

2018-08-10

この流れで多態性もOptionalも出てこないあたりがお察しな感じ。

2016-10-08

違和感を感じた」ってなんでダメなんだっけ?

最近ふと思った

プログラミング説明する

「感じる」っていう関数を考えると、こう書ける

感じる(x)

xの型はもちろん「感じるもの」だ

感じる(カンジルモノ x)

しかし、人間の脳は多態性担保してるので、実際には動的型付けに近い

感じる(var x)

・感じる(暖かさ)

・感じる(力強さ)

・感じる(お昼ご飯)

・感じる(猫)

・感じる(波)

渡されたものが、カンジルモノではなかった場合

人の脳内で渡されたオブジェクトカンジルモノにキャストする(解釈する)

これが基本的自然言語理解仕様だ。

この時、当たり前だが渡されるものカンジルモノである方が、受け手にとっては簡単だ。

まり

感じる(◯◯感)=◯◯感を感じる

というのは非常に理解やす

理解やすいのに、世間ではNG表現となっている

恐らくこれは単に「ダサいから」だろう

「かっこいいコード」をありがたがり、「分かりやすコード」を否定するプログラマーがいるが

あれと同じだ。

ちなみに、感じる(◯◯感)に、そのまま◯◯感を入れるのはバカっぽいというのは分かる

isEmpty(String x)に、isEmpty(string)と渡すより、isEmpty(name)などと

変数名を分かりやすものにした方がいいという主張は分かる

今回の場合はisEmpty(nameString)に近いが。

ただ、「渡すものnameStringという名前からisEmpty(String x)よりisBlank(var x)に渡したい」

というのは意味がわからないだろう?

違和感が◯◯感だから、『感じる』じゃなく『覚える』を使おう」

という主張はそういうことを言っているのだ。

と言うわけで「違和感を感じた」はそれほど悪くないと思う

もちろん「違和感じる」という言葉があれば解決することなのだが

2014-08-05

猟奇的な彼女

S博士の前に可憐なO博士が現れたのは夏の始まりだった。

残酷なほどに照りつける陽光の下、風鈴が涼しく鳴いていた。

博士歴史を塗り替える画期的アイデアがあるのです。私はそれを現実のものにしたいと考えています。」

彼女の師である米国H大学のV教授が、彼女に教えてくれたという。

そのアイデア現実のものであれば細胞生物学においては歴史的大発見である

ES細胞を用いて網膜を形成するなど驚異的な偉業を成し遂げてきたS博士であるが、iPS細胞の出現により最近は影が薄くなってしまった。

研究の意義をよく理解しないお上の人々の独善的な判断により研究費も削られ、窮地に立たされていた。

そんなとき彼女はやってきた。STAP細胞という、従来の常識では考えられない方法で生成された万能細胞というアイデアとともに。

しかし、当初S博士懐疑的であった。酸浴だけで多態性を獲得するだって?そんな現象はありえないね

彼の経験が、直感が、そう言っていた。

秋の朝のことである木々の葉はすっかり落ちてしまい、冬の到来を予感させる。

隣ですやすやと寝息をたてる彼女の横顔が可愛い

普段は硬派で通っている自分が、今回だけは折れてしまった。彼女にはそれだけの魅力があるのだろう。

こんなに親しみやす女性は初めてだ。

やさしく寝顔にキスをする。心も体も軽くなって、S博士はふたたび眠りについた。

「できたぁ!」

数カ月後、O博士はついに偉業を成し遂げた。STAP現象の確認に成功したのである

S博士はその頃別のプロジェクト多忙を極めていたが、彼女成功を耳にして大変うれしく、そして誇りに思った。

「共著者になっていただけないでしょうか。博士のご支援がなければ成功には至らなかったのです。」

愛する彼女からの、嬉しい誘い。

迷うことなく彼は彼女論文に名を連ねた。

その夜は二人で厳かに、愛の術を行った。

栄光を取り戻し、愛を得て、私はなんて幸せなのだろう。

しかし、それは一瞬の夢であった。

彼女実験結果は捏造だった。騙されたっ。

「一体どういうことだ!説明してくれ!」

STAP細胞は、あるの!なんで分からないの!」

「どう逃げるつもりなんだ!明らかに捏造じゃないか!」

ちょっとくらい画像が変だからって何よ!これくらい誰でもやることじゃない。記者会見ではあるって言ってよね!じゃないと私達の関係をバラすわよ!」

S博士は満たされた気持ちから一転、ふたたび窮地に立たされた。

彼女を立てれば、科学良心への反逆である。私は科学の中に生きているのに。

科学を守れば、家族を失う。妻も子も、裏切りと汚辱の中に深い悲しみを受けることだろう。

彼女はありえない選択を迫ってきた。

「なぜ・・・一体なんの恨みがあるんだ・・・

会見の日の夜、彼の横にはいものように彼女が寝ていた。S博士はO博士を取った。

科学なんて糞食らえ。彼女家族も失うくらいなら、こうするしかなかったんだ。

「それでいいの。さすが、あなたは賢いわ。」

複雑な気持ちで愛撫を受ける。このままではいけないことは分かっていた。

それからというもの彼女は豹変した。なぜ私はこの女に顎で使われているんだろう。

ちょっと!早く飯用意しなさいよ!殺すわよ!」

少しでも歯向かおうものなら、暴露をちらつかせ脅迫してきた。

「はやく動けクソジジイ!ほら!」

ひどい。

いつまでこんな生活が続くのだろうか。

愛すべき天使だと思っていた彼女はいしか悪魔に変わっていた。

家族は愛想をつかし、言葉も聞いてくれない。

科学世界の住民からは、失望と驚嘆の眼差しが注がれる。

私はすべてを失った。

風鈴が涼しく鳴った。風鈴は楽で良いな。

私も風鈴になれたら。

2011-12-12

コンピュータプログラミング概念技法モデル」の目次

第1章 プログラミング概念入門
	1.1 計算器
	1.2 変数
	1.3 関数
	1.4 リスト
	1.5 リストについての関数
	1.6 プログラムの正しさ
	1.7 計算量
	1.8 遅延計算
	1.9 高階プログラミング
	1.10 並列性
	1.11 データフロー
	1.12 明示的状態
	1.13 オブジェクト
	1.14 クラス
	1.15 非決定性と時間
	1.16 原子性
	1.17 ここからどこへ行くのか?
	1.18 練習問題

第1部 一般的計算モデル

第2章 宣言的計算モデル
	2.1 実用プログラミング言語定義
		2.1.1 言語の構文
		2.1.2 言語意味
	2.2 単一代入格納域
		2.2.1 宣言的変数
		2.2.2 値格納域
		2.2.3 値生成
		2.2.4 変数識別子
		2.2.5 識別子を使う値生成
		2.2.6 部分値
		2.2.7 変数の,変数への束縛
		2.2.8 データフロー変数
	2.3 核言語
		2.3.1 構文
		2.3.2 値と型
		2.3.3 基本型
		2.3.4 レコード手続き
		2.3.5 基本操作
	2.4 核言語意味
		2.4.1 基本概念
		2.4.2 抽象マシン
		2.4.3 待機不能な文
		2.4.4 待機可能な文
		2.4.5 基本概念再訪
	2.5 メモリ管理
		2.5.1 末尾呼び出し最適化
		2.5.2 メモリライフサイクル
		2.5.3 ガーベッジコレクション
		2.5.4 ガーベッジコレクションは魔術ではない
		2.5.5 Mozartのガーベッジコレクタ
	2.6 核言語から実用言語へ
		2.6.1 構文上の便宜
		2.6.2 関数(fun文)
		2.6.3 対話的インターフェース(declare文)
	2.7 例外
		2.7.1 動機と基本概念
		2.7.2 例外を持つ宣言的モデル
		2.7.3 親言語の構文
		2.7.4 システム例外
	2.8 進んだ話題
		2.8.1 関数型プログラミング言語
		2.8.2 単一化と内含(entailment)
		2.8.3 動的型付けと静的型付け
	2.9 練習問題

第3章 宣言的プログラミング技法
	3.1 宣言的とはどういうことか?
		3.1.1 宣言的プログラムの分類
		3.1.2 仕様記述言語
		3.1.3 宣言的モデルにおいてコンポーネントを実装すること
	3.2 反復計算
		3.2.1 一般的図式
		3.2.2 数についての反復
		3.2.3 局所的手続きを使うこと
		3.2.4 一般的図式から制御抽象へ
	3.3 再帰計算
		3.3.1 スタックの大きさの増加
		3.3.2 代入ベース抽象マシン
		3.3.3 再帰計算を反復計算に変換すること
	3.4 再帰を用いるプログラミング
		3.4.1 型の記法
		3.4.2 リストについてのプログラミング
		3.4.3 アキュムレータ
		3.4.4 差分リスト
		3.4.5 キュー
		3.4.6 木
		3.4.7 木を描画すること
		3.4.8 構文解析
	3.5 時間効率空間効率
		3.5.1 実行時間
		3.5.2 メモリ使用量
		3.5.3 償却的計算量
		3.5.4 性能についての考察
	3.6 高階プログラミング
		3.6.1 基本操作
		3.6.2 ループ抽象
		3.6.3 ループ言語的支援
		3.6.4 データ駆動技法
		3.6.5 明示的遅延計算
		3.6.6 カリー化
	3.7 抽象データ型
		3.7.1 宣言的スタック
		3.7.2 宣言的辞書
		3.7.3 単語出現頻度アプリケーション
		3.7.4 安全抽象データ型
		3.7.5 安全な型を備えた宣言的モデル
		3.7.6 安全な宣言的辞書
		3.7.7 資格セキュリティ
	3.8 宣言的でない必要物
		3.8.1 ファイルを伴うテキスト入出力
		3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力
		3.8.3 ファイルとの状態なしデータI/O
	3.9 小規模プログラム設計
		3.9.1 設計方法
		3.9.2 プログラム設計の例
		3.9.3 ソフトウェアコンポーネント
		3.9.4 スタンドアロンプログラムの例
	3.10 練習問題

第4章 宣言的並列性
	4.1 データ駆動並列モデル
		4.1.1 基本概念
		4.1.2 スレッド意味
		4.1.3 実行列
		4.1.4 宣言的並列性とは何か?
	4.2 スレッドプログラミングの基本的技法
		4.2.1 スレッドを生成すること
		4.2.2 スレッドブラウザ
		4.2.3 スレッドを使うデータフロー計算
		4.2.4 スレッドスケジューリング
		4.2.5 協調的並列性と競合的並列性
		4.2.6 スレッド操作
	4.3 ストリーム
		4.3.1 基本的生産者消費者
		4.3.2 変換器とパイプライン
		4.3.3 資源管理し,処理能力改善すること
		4.3.4 ストリームオブジェクト
		4.3.5 ディジタル論理シミュレーション
	4.4 宣言的並列モデルを直接使うこと
		4.4.1 順序決定並列性
		4.4.2 コルーチン
		4.4.3 並列的合成
	4.5 遅延実行
		4.5.1 要求駆動並列モデル
		4.5.2 宣言的計算モデル
		4.5.3 遅延ストリーム
		4.5.4 有界バッファ
		4.5.5 ファイルを遅延的に読み込むこと
		4.5.6 ハミング問題
		4.5.7 遅延リスト操作
		4.5.8 永続的キューアルゴリズム設計
		4.5.9 リスト内包表記
	4.6 甘いリアルタイムプログラミング
		4.6.1 基本操作
		4.6.2 ティッキング(ticking)
	4.7 Haskell言語
		4.7.1 計算モデル
		4.7.2 遅延計算
		4.7.3 カリー化
		4.7.4 多態型
		4.7.5 型クラス
	4.8 宣言的プログラム限界拡張
		4.8.1 効率性
		4.8.2 モジュラ性
		4.8.3 非決定性
		4.8.4 現実世界
		4.8.5 正しいモデルを選ぶこと
		4.8.6 拡張されたモデル
		4.8.7 異なるモデルを一緒に使うこと
	4.9 進んだ話題
		4.9.1 例外を持つ宣言的並列モデル
		4.9.2 さらに遅延実行について
		4.9.3 通信チャンネルとしてのデータフロー変数
		4.9.4 さらに同期について
		4.9.5 データフロー変数有用性
	4.10 歴史に関する注記
	4.11 練習問題

第5章 メッセージ伝達並列性
	5.1 メッセージ伝達並列モデル
		5.1.1 ポート
		5.1.2 ポート意味
	5.2 ポートオブジェクト
		5.2.1 NewPortObject抽象
		5.2.2 例
		5.2.3 ポートオブジェクトに関する議論
	5.3 簡単なメッセージプロトコル
		5.3.1 RMI(遠隔メソッド起動)
		5.3.2 非同期RMI
		5.3.3 コールバックのあるRMI(スレッド使用)
		5.3.4 コールバックのあるRMI(継続のためのレコード使用)
		5.3.5 コールバックのあるRMI(継続のための手続き使用)
		5.3.6 エラー報告
		5.3.7 コールバックのある非同期RMI
		5.3.8 二重コールバック
	5.4 並列性のためのプログラム設計
		5.4.1 並列コンポーネントを使うプログラミング
		5.4.2 設計方法
		5.4.3 並列性パターンとしての機能的構成要素
	5.5 リフト制御システム
		5.5.1 状態遷移図
		5.5.2 実装
		5.5.3 リフト制御システムの改良
	5.6 メソッド伝達モデルを直接使用すること
		5.6.1 1つのスレッドを共有する複数のポートオブジェクト
		5.6.2 ポートを使う並列キュー
		5.6.3 終点検出を行うスレッド抽象
		5.6.4 直列依存関係の除去
	5.7 Erlang言語
		5.7.1 計算モデル
		5.7.2 Erlangプログラミング入門
		5.7.3 receive操作
	5.8 進んだ話題
		5.8.1 非決定性並列モデル
	5.9 練習問題

第6章 明示的状態
	6.1 状態とは何か?
		6.1.1 暗黙的(宣言的)状態
		6.1.2 明示的状態
	6.2 状態とシステム構築
		6.2.1 システムの性質
		6.2.2 コンポーネントベースプログラミング
		6.2.3 オブジェクト指向プログラミング
	6.3 明示的状態を持つ宣言的モデル
		6.3.1 セル
		6.3.2 セル意味
		6.3.3 宣言的プログラミングとの関係
		6.3.4 共有と同等
	6.4 データ抽象
		6.4.1 データ抽象組織する8つの方法
		6.4.2 スタックの変種
		6.4.3 多態性
		6.4.4 引数受け渡し
		6.4.5 取り消し可能資格
	6.5 状態ありコレクション
		6.5.1 インデックス付きコレクション
		6.5.2 インデックス付きコレクションを選ぶこと
		6.5.3 その他のコレクション
	6.6 状態に関する推論
		6.6.1 不変表明
		6.6.2 例
		6.6.3 表明
		6.6.4 証明規則
		6.6.5 正常終了
	6.7 大規模プログラム設計
		6.7.1 設計方法
		6.7.2 階層システム構造
		6.7.3 保守性
		6.7.4 将来の発展
		6.7.5 さらに深く知るために
	6.8 ケーススタディ
		6.8.1 遷移的閉包
		6.8.2 単語出現頻度(状態あり辞書を使用する)
		6.8.3 乱数を生成すること
		6.8.4 口コミシミュレーション
	6.9 進んだ話題
		6.9.1 状態ありプログラミング限界
		6.9.2 メモリ管理と外部参照
	6.10 練習問題

第7章 オブジェクト指向プログラミング
	7.1 継承
	7.2 完全なデータ抽象としてのクラス
		7.2.1 例
		7.2.2 この例の意味
		7.2.3 クラスオブジェクト定義すること
		7.2.4 クラスメンバ
		7.2.5 属性初期化すること
		7.2.6 第1級メッセージ
		7.2.7 第1級の属性
		7.2.8 プログラミング技法
	7.3 漸増的データ抽象としてのクラス
		7.3.1 継承グラフ
		7.3.2 メソッドアクセス制御(静的束縛と動的束縛)
		7.3.3 カプセル化制御
		7.3.4 転嫁委任
		7.3.5 内省
	7.4 継承を使うプログラミング
		7.4.1 継承の正しい使い方
		7.4.2 型に従って階層を構成すること
		7.4.3 汎用クラス
		7.4.4 多重継承
		7.4.5 多重継承に関するおおざっぱな指針
		7.4.6 クラス図の目的
		7.4.7 デザインパターン
	7.5 他の計算モデルとの関係
		7.5.1 オブジェクトベースプログラミングコンポーネントベースプログラミング
		7.5.2 高階プログラミング
		7.5.3 関数分解と型分解
		7.5.4 すべてをオブジェクトにすべきか?
	7.6 オブジェクトシステムを実装すること
		7.6.1 抽象図
		7.6.2 クラスを実装すること
		7.6.3 オブジェクトの実装
		7.6.4 継承の実装
	7.7 Java言語(直列部分)
		7.7.1 計算モデル
		7.7.2 Javaプログラミング入門
	7.8 能動オブジェクト
		7.8.1 例
		7.8.2 NewActive抽象
		7.8.3 フラウィウス・ヨセフスの問題
		7.8.4 その他の能動オブジェクト抽象
		7.8.5 能動オブジェクトを使うイベントマネージャ
	7.9 練習問題

第8章 状態共有並列性
	8.1 状態共有並列モデル
	8.2 並列性を持つプログラミング
		8.2.1 さまざまな手法概観
		8.2.2 状態共有並列モデルを直接使うこと
		8.2.3 原子アクションを使うプログラミング
		8.2.4 さらに読むべき本
	8.3 ロック
		8.3.1 状態あり並列データ抽象を構築すること
		8.3.2 タプル空間(Linda)
		8.3.3 ロックを実装すること
	8.4 モニタ
		8.4.1 定義
		8.4.2 有界バッファ
		8.4.3 モニタを使うプログラミング
		8.4.4 モニタを実装すること
		8.4.5 モニタの別の意味
	8.5 トランザクション
		8.5.1 並列性制御
		8.5.2 簡易トランザクションマネージャ
		8.5.3 セルについてのトランザクション
		8.5.4 セルについてのトランザクションを実装すること
		8.5.5 トランザクションについてさらに
	8.6 Java言語(並列部分)
		8.6.1 ロック
		8.6.2 モニタ
	8.7 練習問題

第9章 関係プログラミング
	9.1 関係計算モデル
		9.1.1 choice文とfail文
		9.1.2 探索木
		9.1.3 カプセル化された
		9.1.4 Solve関数
	9.2 別の例
		9.2.1 数値例
		9.2.2 パズルとnクイーン問題
	9.3 論理プログラミングとの関係
		9.3.1 論理論理プログラミング
		9.3.2 操作意味論理意味
		9.3.3 非決定性論理プログラミング
		9.3.4 純粋Prologとの関係
		9.3.5 他のモデルにおける論理プログラミング
	9.4 自然言語構文解析
		9.4.1 簡単な文法
		9.4.2 この文法に従う構文解析
		9.4.3 構文木を生成すること
		9.4.4 限定記号を生成すること
		9.4.5 パーサを走らせること
		9.4.6 パーサを「逆向きに(backward)」走らせること
		9.4.7 単一化文法
	9.5 文法インタプリタ
		9.5.1 簡単な文法
		9.5.2 文法のコード化
		9.5.3 文法インタプリタを走らせること
		9.5.4 文法インタプリタを実装すること
	9.6 データベース
		9.6.1 関係を定義すること
		9.6.2 関係を使って計算すること
		9.6.3 関係を実装すること
	9.7 Prolog言語
		9.7.1 計算モデル
		9.7.2 Prologプログラミング入門
		9.7.3 Prologプログラムを関係プログラム翻訳すること
	9.8 練習問題

第2部 特殊化された計算モデル10グラフィカルユーザインタフェースプログラミング
	10.1 宣言的/手続き的方法
	10.2 宣言的/手続き的方法を使うこと
		10.2.1 基本的ユーザインタフェースの要素
		10.2.2 GUIを構築すること
		10.2.3 宣言的座標
		10.2.4 リサイズ時の宣言的振る舞い
		10.2.5 ウィジェットの動的振る舞い
	10.3 対話的学習ツールPrototyper
	10.4 ケーススタディ
		10.4.1 簡単なプログレモニタ
		10.4.2 簡単なカレンダウィジェット
		10.4.3 ユーザインタフェースの動的生成
		10.4.4 状況順応時計
	10.5 GUIツールを実装すること
	10.6 練習問題

第11章 分散プログラミング
	11.1 分散システムの分類
	11.2 分散モデル
	11.3 宣言的データの分散
		11.3.1 オープン分散と大域的ネーミング
		11.3.2 宣言的データを共有すること
		11.3.3 チケット配布
		11.3.4 ストリーム通信
	11.4 状態の分散
		11.4.1 単純状態共有
		11.4.2 分散字句的スコープ
	11.5 ネットワークアウェアネス
	11.6 共通分散プログラミングパターン
		11.6.1 静的オブジェクトモバイルオブジェクト
		11.6.2 非同期的オブジェクトデータフロー
		11.6.3 サーバ
		11.6.4 クローズド分散
	11.7 分散プロトコル
		11.7.1 言語実体
		11.7.2 モバイル状態プロトコル
		11.7.3 分散束縛プロトコル
		11.7.4 メモリ管理
	11.8 部分的失敗
		11.8.1 失敗モデル
		11.8.2 失敗処理の簡単な場合
		11.8.3 回復可能サーバ
		11.8.4 アクティブフォールトトレランス
	11.9 セキュリティ
	11.10 アプリケーションを構築すること
		11.10.1 まずは集中,後に分散
		11.10.2 部分的失敗に対処すること
		11.10.3 分散コンポーネント
	11.11 練習問題

第12章 制約プログラミング
	12.1 伝播・探索法
		12.1.1 基本的考え方
		12.1.2 部分情報を使って計算すること
		12.1.3 例
		12.1.4 この例を実行すること
		12.1.5 まとめ
	12.2 プログラミング技法
		12.2.1 覆面算
		12.2.2 回文積再訪
	12.3 制約ベース計算モデル
		12.3.1 基本的制約と伝播子
		12.3.2 計算空間の探索をプログラムすること
	12.4 計算空間定義し,使うこと
		12.4.1 深さ優先探索エンジン
		12.4.2 検索エンジンの実行例
		12.4.3 計算空間の生成
		12.4.4 空間の実行
		12.4.5 制約の登録
		12.4.6 並列的伝播
		12.4.7 分配(探索準備)
		12.4.8 空間の状態
		12.4.9 空間クローン
		12.4.10 選択肢を先に任せること
		12.4.11 空間マージすること
		12.4.12 空間失敗
		12.4.13 空間計算を注入すること
	12.5 関係計算モデルを実装すること
		12.5.1 choice文
		12.5.2 Solve関数
	12.6 練習問題

第3部 意味

第13章 言語意味
	13.1 一般的計算モデル
		13.1.1 格納域
		13.1.2 単一代入(制約)格納域
		13.1.3 抽象構文
		13.1.4 構造的規則
		13.1.5 直列実行と並列実行
		13.1.6 抽象マシン意味との比較
		13.1.7 変数導入
		13.1.8 同等性の強制(tell)
		13.1.9 条件文(ask)
		13.1.10 名前
		13.1.11 手続抽象
		13.1.12 明示的状態
		13.1.13 by-need同期
		13.1.14 読み出し専用変数
		13.1.15 例外処理
		13.1.16 失敗値
		13.1.17 変数置き換え
	13.2 宣言的並列性
		13.2.1 部分停止と全体停止
		13.2.2 論理同値
		13.2.3 宣言的並列性の形式的定義
		13.2.4 合流性
	13.3 8つの計算モデル
	13.4 よくある抽象意味
	13.5 歴史に関する注記
	13.6 練習問題

2009-10-29

http://anond.hatelabo.jp/20091029170021

もちろんそういう話は考慮した上で言ってるんです。

だから「使いこなせるかどうかはさておき」とわざわざ前置きしたわけで。

(つまり、「理解する」という言葉意味を限定しているわけです)

まぁ多態性についてはそれなりに理解してないと話にならないだろうし、

デザインパターンオブジェクト指向概念そのものみたいなところがあるので、

オブジェクト指向をそれなりに理解してるなら必然的に理解してることになると思いますが。

(個別のパターンクラス図を丸暗記したところであまり意味は無いし、それは理解したとは言わないということです)

2008-07-04

http://anond.hatelabo.jp/20080704003545

Factory Methodパターンでもいいんじゃね。

もしかしたら、Strategyパターンかもしれないけれど、

デザインパターンって、多態性意識したものが多いから、何でもいけそう。

switchポリモーフィズムのはざまで

多態性(ポリモーフィズム)を目論んでいたはずが、いつのまにかコードにif文とswitch文の渦が紛れ込んでる。

switch ( FLAG ) {
    case 1:
    {
        object = new ObjectA();
    }
    case 2:
    {
        object = new ObjectB();
    }
    default:
    {
        object = new ObjectC();
    }
}

object->doSomething();

せっかく多態性を実現しているのに、なんでswitch文で場合分けしなければいけないのか。

嫌だあ、switch文使いたくない!

ない!ない!

2007-10-08

とある元エセ数学屋のぶつくさ

「頭のいい人は説明もうまい」問題で、一番肩身が狭いのが数学屋と哲学屋。哲学屋さんの弁解は哲学屋さんに任せるとして、エセ数学屋の立場からその弁解を書かせて欲しい(哲学屋さんも事情は似たようなものだと思うけれど)。

まず、世間では誤解されてると思うのだが、数学というのは理系の他分野(物理学とか、生物学とか)とは少し性格が違う。数学は、具体的な対象を想定しない。むしろ、具体的な対象と遊離したところを記述するための「言葉」を作る学問なのだ。

よく言われることだが、新たな数学理論発見とは、わかりやすい概念や記号法を発明することといっても過言ではない。一番わかりやすいのが「未知数をxなど文字で置き換える」というものだろう。これによって、古代エジプト古代ギリシャ賢者大勢を悩ませた問題も、中学生の練習問題に早変わりする。しかし一方で、多くの賢人を悩ませた問題を少数の記号やキーワードに集約するのだから、そもそもそんなものを簡単に説明できる方がおかしい。中学校あたりから数学が途端に難しくなるのはこのためだ。

抽象概念を説明することの難しさは、プログラミング世界とも共通している点があるだろう。たとえば、「多態性 (polymorphism)」という言葉機械音痴の人に説明できるだろうか、考えてみてほしい(このたとえのわからない人は、次の段落まで読み飛ばしてほしい)。もちろん、例えば「同じ『鳴く』という動作でも、犬は『ワン』で、猫は『ニャー』だ」などと、わかった気にさせるようなたとえ話でごまかすことはできるだろう。だが、そんな「説明」が役に立たないことは明らかだ。「そんなことの何がすごいのか、ポリバレントだかなんだか知らないがそんな偉そうな名前をつけるほどのことか」とかいわれて終わりである。現実に「説明」を求められる場合とは、「誰かに金を出させるために説得しなければいけない場合」なのである。ユーザ企業に「オブジェクト指向による開発」の必要性を説得するとき、そのような子供だましでは金を出してもらえないことは明らかだろう。

そして数学は、プログラミング言語よりもっと包括的に「人間の思考の一部を記述する言語」なのである(正確には、コンピュータサイエンス数学の一分野である)。そして、プログラミング言語などという概念たかだかこの数十年のものにすぎないが、近代数学は数百年の積み重ねがあるのである。素人専門家の乖離にもそれだけの差があると思ってもらって構わない。説明が絶望的に困難なことは明らかだ。その困難さは、たとえば英語を知らない子供に「関係代名詞」を説明するのと同じぐらい難しい。いや、数学は「頭の中の普段使っていない部分」を使う言語だから、英語などよりもっと難しいと言っていいかもしれない。英語日本語の間では直訳はできないことはないが、数学語やプログラミング言語日本語の直訳は不可能だからだ(できるのならば、プログラマは全員失業である)。

しかし、こうした事情を多くの人はわかってくれない。そこで、「数学屋(と哲学屋)は物事をわざわざ小難しく説明する権威主義者だ」だの「他の分野の専門家に比べて説明能力に欠けている」だのと非難を浴びるのである。こういうハンディを背負っていることがなかなかわかってもらえないのである。

追記

多態性のあたりはあまりいい例ではなかったかもしれない。犬はワンで猫はニャーというのは、多態性という概念の発想を適切にとらえたたとえ話ではあるからだ。純粋数学の場合は、こういうわかりやすい例が見あたらないものも多いのである(たとえば「解析関数」を「複素数」や「微分」を知らない人に説明するとなるともうお手上げだ)。無論、こういうたとえ話が、多態性概念プログラミング世界でいかに有用であるかを説明することにほとんど貢献していないのは明らかだけれども。プログラミング経験がない人には、それだけのことがいかに役に立つのかなど到底実感ではわかってもらえないだろう。

蛇足

なお、こんな記事が話題になっているが、この程度の説明ならまともな数学屋なら誰でもできるので念のため。このスレッドの住人はsinとかcosのような高校数学概念も怪しかったわけだが、そんな人を相手に文中に出てきた「バナッハ空間」だの「ヒルベルト空間」だのの説明をさせられたらとても困っていたはずである。正直、これらの概念専門家には「イロハのイ」レベルのことに過ぎないが、ピアノで「猫踏んじゃった」しか弾けない人に「エリーゼのために」を教え込むのと同じぐらいは難しいだろうと思う。それぐらいのレベルの差がある。

蛇足の蛇足

ついでに、上のスレッドで挙がっている「日本語論理的でない」とか「英語フランス語数学に向いている」というのはウソと言える。言語能力は、相互に翻訳ができれば等価であるといってよいからだ。実際問題としては、論理的で厳密な文章ほど、直訳は簡単である。つまり、言語による論理能力の差というものは存在しないといってよいのだ。言語によって一番表現力の差が生じるのは、むしろ「前衛詩」のような、一番「論理的でない」部分である。

2007-08-24

http://anond.hatelabo.jp/20070824002312

OOPプログラミングに有利なのには同意。

しかし、OOPは各オブジェクトの構造や関連に注目した記述となるため、自然言語との親和性が手続き型よりも低い。オブジェクト指向は視覚的なアプローチなのに対し、手続き型言語言葉による理解。一昔前の言葉で言えば、ランダムアクセスとシーケンシャルアクセス並の違いがある。

OOP人間界、、、人間世界観に沿っているのは同意するが、人間言葉に合わせているのではない。

また、「xxx.doThat()」を羅列しただけのようなプログラムOOPではない。それは手続き型だ。

ちなみに俺はOOPの利点は、メソッド・変数群の名前空間の整理(大規模プログラムを書いても名前が混乱しにくい)、データカプセル化(複数の違うフォーマットデータを同じもののように扱える。多態性)であると思っている。分析との親和性についてはオブジェクトデータフローペトリネットも大して差がない。

いや、なんていうか覚え立ての言葉をいろいろ使ってみたかっただけだ、すまん。

 
ログイン ユーザー登録
ようこそ ゲスト さん