- オブジェクト指向なんて今すぐやめてください
937 ：デフォルトの名無しさん[sage]：2014/09/03(水) 20:33:59.58 ID:z1Y/3x7f - >>936
たしかに ExactlyOne-to-ExactolyOne の関係は、ほとんど無いと思う
（ここで、"exactly one" とは「厳密に1」とか「きっかり1」という意味）
ただし ExactlyOne-to-ZeroOrOne の関係は、ありふれていると思う
もし「あんまりない」と思うのなら、
それは nullable な属性を見落としているのではないのだろうか？
なお、世界には多夫一妻制の民族もあると聞いた事があるから(アフリカだったかな？)、
一夫多妻制を考慮するのなら Many-to-Many または OneOrMore-to-OneOrMore 関係と
しないと、某ジェンダーフリー団体関係者から女性蔑視と批判されかねないからご注意を
|
- 集合論に基づいた言語を作りたい
159 ：デフォルトの名無しさん[sage]：2014/09/03(水) 20:49:03.08 ID:z1Y/3x7f - >>158
>デカいオブジェクトの一部を更新しようとしたら丸コピーするんでしょ？
そんな馬鹿はしない
更新した項目(名前と更新値のペア)が新しい環境へ追加されるだけ
それ以外の項目は古い環境をさかのぼって検索すれば参照できる
（一般には検索結果はメモ化されるから、２回目以降の検索は遅くならない）
ただし副作用のない世界におけるデータ構造に関する
効率的な実装アルゴリズムは発展途上にある
（世の中の歴史的なアルゴリズムの大半は副作用を前提にしているからね）
たとえばこんなのが分かりやすいと思う
・20分でわかる Purely Functional Data Structures - Kmonos.net
http://www.kmonos.net/pub/Presen/PFDS.pdf
|
- クラス名・変数名に迷ったら書き込むスレ。Part24
752 ：デフォルトの名無しさん[sage]：2014/09/03(水) 21:40:35.62 ID:z1Y/3x7f - >>748
メッセージの種類とは無関係に「処理」するメソッドなのだから、
その命名も総称的・抽象的になるのは必然的だと思う
たとえば >>750 の execute(=実行する)でもいいと思うし、
他の候補には process(=処理する) とか accept(=受付ける) などがある
こうした、ある総称的・抽象的な動詞に対して XXXMessage や YYYMessage といった
メッセージの種類(クラス)に応じて振る舞いが変化することが、オブジェクト指向の持つ
特徴の一つであり「ポリモーフィズム(=多態性 or 多相性)」と呼ばれる重要な概念になる
今回あえて修飾子を付け加えるとしたら、受信したレスポンスのメッセージなのだから、
received(=受信した) とか response(=応答) を検討するのがいいと思う
ここでは「表と裏」「真と偽」「成功と失敗」といった「対称性」が重要な概念であり、
ここでは「送信(send)と受信(receive)」と「要求(request)と応答(response)」になる
おそらく「リクエストメッセージ送信処理」メソッドの命名に関しても同様に悩んでいると思う
対照的な二つの概念を切り離さず、対称性を考慮し全体的なバランスを意識した命名法を検討しよう
（レスの主旨はこれで終わりだけど、オマケ的な補足を次に続ける）
|
- クラス名・変数名に迷ったら書き込むスレ。Part24
753 ：デフォルトの名無しさん[sage]：2014/09/03(水) 22:03:57.60 ID:z1Y/3x7f - (>>752の続き)
なおネットワークに関わる技術者なら「OSI参照モデル」という用語を聞いた事があると思う
実は OSI は(普及する事なく歴史に埋もれて参照モデル以外は忘れ去られているけど)TCP/IPスイートと同様に
各レイヤーのプロトコルの定義から構成される通信アーキテクチャの一つであり、ISO/JIS規格化されている
この OSI は(米 IBM SNA 対抗として)欧州勢が関わった結果、概念としてよく整理されている
その概念の一部を紹介する（これら概念はデータリンク層からアプリケーション層まで一貫して適用される）：
・ある層(レイヤー)の通信プロトコルが提供する機能の全体を「サービス(service)」と呼ぶ
・サービスには、それに関わる「エンティティ(entity)」がいて、
それらは(サービスの)「提供者(provider)と利用者(user)」へと二分される
（今風の言葉であれば「オブジェクト」および「サーバとクライアント」になるだろう」
・通信の基本手順は以下の４段階になる：
(1) 要求(requrest)：
利用者が利用者側サービスに対してある操作 XXX を「要求」すると、XXX要求メッセージが送信される
(2) 通知(indicate)：
XXX要求メッセージを受信した提供者側サービスは、提供者へ操作 XXX の到着を「通知」する
(3) 応答(response)：
提供者が操作 XXX を実行して結果を提供者側サービスへ「応答」すると、XXX 応答メッセージが送信される
/* 注：返信だからメッセージの流れる方向が (1) とは逆で、「提供者側 -> 利用者側」になる */
(4) 確認(confirm)：
XXX 応答メッセージを受信した利用者側サービスは、利用者へ操作 XXX の結果を「確認」する
もしも仮に極端に長い命名をしてみると今回のケースは (4) に該当するから、
たとえば confirm_received_response_message になる（が、常識的にはずっと短くできるはず）
参考まで
|
- スレ立てるまでもない質問はここで 138匹目
183 ：デフォルトの名無しさん[sage]：2014/09/03(水) 22:38:35.56 ID:z1Y/3x7f - おいら岬の 灯台守は
妻と２人で 沖行く船の
無事を祈って
灯をてらす 灯〜をてらす
|
- 【Python】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ46【pl,rb,php,js】
179 ：デフォルトの名無しさん[sage]：2014/09/03(水) 23:10:40.67 ID:z1Y/3x7f - >>176
で、Git もスクリプトだからという理由で、
スレ違いの議論を延々と続けようとしている訳か....
|