vieweditattachhistoryswikistopchangessearchhelp

ソフトウェア配線

クラスだかオブジェクトだかをIC(部品)に喩える、という言い方があったと思いますが、
あれが今なかなか実用化されてない(^^;のは何故か？を考えてるうちに、
ふと思い浮かんだキーワードが、「ソフトウェア配線」。

ICが有るなら、その「間」を繋ぐ「配線」も、有る(定義しておく)必要があるんじゃなかろうか？
そして、配線を定義しないと、ICだけじゃどうせ結線できなくて回路が作れない(!)んだから、部品化が旨くいかないのも道理…
ということだったりするまいか？と。

というわけで、オブジェクト指向や、もしかしてプログラム全般において、
配線に相当するものは一体なんなんだろう？と、ちょっと考えてみたくなった次第。 --戯
(ちなみに、またしても寝坊して、今から楽器フェア2003に行けるかどうか微妙な俺…)


アラン・ケイの“ma”

くしくも、アラン・ケイも“間”に言及していますね。
もっともこちらは、メッセージ送信を表す言葉としてですが。 --sumim

うーん。日本的なあの「間(ま)」が存在するだけなら、俺としては別段嬉しくないんですよね。
だって、その「間」に何があるかは、曖昧模糊(日本文化お得意の)としたままなんだもん。
＃ケイ氏の英文はまだ読み終えていませんので、ちょいずれてるかもだけど。

俺が欲しいのは、間(あいだ)を「繋ぐ」ものです。確かに繋ぐものです。曖昧なものじゃなく。

少し一例を具体的に言うならば、メッセージが「どこからどこへ」伝わるか？を、
もっとはっきり見え易くしたい。

イライラしてるのが関数やメッセージの「引数」という奴です。
あの発想って、実世界の配線に喩えて言うならば、
必要な瞬間(秒単位？もっと短く？)だけコネクタを繋いで、終わったら即はずす、
というような忙しい(せわしい)ものです。

刹那すぎるんですよ。
忙しいので、ドコがドコにどう繋がっているのかが、「見えにくい」。
この見えにくさが、デバッグのしにくさに繋がってるような気がしてならん。

繋いで「おき」たいんです。--戯


抽象化は進むが多態性が失われない？

抽象化（による設計や実装のしやすさ）と（そうして出来上がったものの）デバグのしやすさというのは、
パラレルだと思っていたのですが、必ずしもそうではないので分けて考える必要があるのですかね。--sumim

んー。(この場合の)パラレルってのがどういう意味かがよく判りませんが、
こっちが考えていることは、
「(この規格に合う場所になら)どこにでも接続できるよ」っていうのと
「この線は「今は、ここに」接続されているよ」っていうのとは、
当然ですが同時に言えますよ、っていう話です。

で、現在主流の「引数」方式は、前者は見えるものの、後者が見えにくくなっちゃってると思います。
接続可能性は(シグネチャの引数群の型とか、メッセージの命名ノリなどで)おおよそ判りますが、
今どう繋がってるかは何の痕跡も残っていない。

ラジオや車をぶっ壊し(^^;たら、電球にケーブルが繋がってる。
それを手繰ればその先にまた何かが有り、なにがしかの情報が得られる。

ああいう境地が欲しいんです。

現状だと、それを妨げているものは2つあって、

まず、Smalltalk以外の多くの(^^;言語/環境が「実行とプログラム作成を分けている」ので、
ぶっ壊して中を見たり、ましてやケーブル(またはその痕跡)を見ることなんて、そもそも無理っていう点。

そして次(つまりSmalltalkでも克服されてない問題)が、この「配線」の欠如なんです。
プログラムが「まさに動いている間(しかも「そのメソッドが呼ばれた瞬間」)」しか繋がりが見えない。 --戯

そうした機構や“しばり”は、たしかにデバグをしやすくしますが、動的結合とは背反しませんか？

ところで、Smalltalk 環境では、そのメソッドに実行時に繋がる可能性のある配線（をたぐった先のメソッド）を
かなり機械的にですが senders of や implementors of で列挙することはできます。
これをもっと厳密にして理論上繋がる可能性があるものだけにせよ、という解釈でよいなら実際欲しいと思いますし、
おっしゃることも分かるような気もします。--sumim

ML などにある型推論の世界とは、また違うのでしょうか。--sumim

いえ。(勿論俺が見込み違えてなければの話ですが)
動的結合とも相性ばっちりですし、型推論とは無関係なはずです。

俺が言いたい(解決したい＆「配線」したい)のは、「型じゃなくロール」の問題なのです。

「どういう規格のコネクタに繋ぐことが出来るか」みたいな接続可能性の問題は、
現実的なプログラミングでは、しばしば型の問題に落とし込まれています。

で、俺がやりたいのはそっちじゃなく、じゃあ今目の前に300個のDINジャックが有ったとして、
自分が今持ってるこのオブジェクトのこのDINプラグを、今自分は「どの」ジャックに刺した(刺しといた)か？を
見えるようにしたいんです。

ラジオをバラして、配線を「違うところ」に繋ぎ直して、それから一見元通りに蓋をすることは、できるでしょ。
そして、その時どう繋ぎ直したかは、後で再びバラしてケーブルを見れば判る。
ああいう感じ。

なお、ジャックやプラグには、作り次第で、型みたいな意味での縛りを入れることも入れないことも
どちらも可能です。
DINがミニに刺さらないのは言わば型制約みたいなもの。
いっぽう、剥き出し線をマイキットみたいに(^^;繋ぐとか、
あるいは特定のジャック/プラグ規格を使うにせよそれをシステム全体で1種類しか使わない
(アナログシンセのパッチケーブルの世界？)とか、ということにすれば、
それは型なしの世界に相当します。

＃あと、ケーブルが何芯かとか、定格電流とか、そういう概念も存在してもいいとは思っています。ただしOptionalね。

>これをもっと厳密にして理論上繋がる可能性があるものだけにせよ、という解釈でよいなら

NO。むしろ逆かな。
プラグがどのジャックに「刺さり得る」かじゃなく、
プラグがどのジャックに「刺さってる」かを表現したい。

なお、まさにそのメソッドの処理中にしかその「刺さってる」が参照できないモデルは、俺にとっては不足です。
使ってないときもプラグはジャックに刺しとける。あの感じをやりたい。 --戯

ところで、とても単純かつ実現可能(つーか既に実現してる)なんですが、
実は オブジェクトのいわゆる属性は、実は配線とほぼ同等な存在です(^^;
属性は、オブジェクトに何かを「いったん持たせる」というモデル。
配線と同じようなもんです。

問題は、属性以外のオブジェクト間の情報伝達手段(つーか、伝達「され」情報としてのオブジェクト)である、
メソッド呼んだときの「引数」と、あと「返し値」のほうなんです。
引数は刹那なんで困ってしまう。

そうですねー。卑近な代用実装としては、
selfの属性で参照してるオブジェクト「以外」を引数としてメソッドを呼んだら必ず例外吐く
…みたいなシステム辺りが、試作品第一歩かな。

＃そんなのStringや数値で困り果てるだろ、という指摘はご尤もなので、これだけじゃ即使えやしないですが。 --戯

ん。サブタイトルとかに「抽象」という言葉が有るが、俺は一言も抽象って言ってませんのでヨロシクね。

言っていないし、実際(?)にも抽象度は全く変化しない(上がりも下がりもしない)んじゃなかろうか？と思う。
まだよく考察してないけど恐らく…

では何が変わるんだろ？

ちょっと考えたが、これは寿命(だけ)が代わるんじゃないかな？
何の寿命かといえば、「メッセージをやりとりする相手の特定っぷり」の寿命、とでもいうか、そういうもの。
＃ま、これはどっちかってーと、「予約」とかの概念の説明そのものかも知れないけど。 --戯

ちょっと思ったんだけど、

>動的結合とは背反しませんか？

もしかして、(これを書かれた時点では) プログラムには「動的」と「静的」の2つのモードが有る
(ってゆーか2つのモードしかない)と思ってらっしゃったりしたんじゃないでしょうか？

卑近な言い方をすれば多分、配線なシステムでは、モードは最低でも3つ有るんだと思います。
つまり「実行(所謂動的な状態)」と「コーディング(みたいな静的な奴)」と、そして「配線」モード。

(個人的な)イメージとしては、Delphiの「設計モード」ですね。
オブジェクト(Widgetでもそれ以外でも可)を画面に並べる(非Widgetは並べても「実行時」には表示されませんが)
という作業をして、かつオブジェクト間の参照関係もいじれます。
で、いじるとき、いろいろな制約をかけられるわけです。変な(そのオブジェクトにとって望ましくない)参照を
設定しようとしたらExceptionが出てユーザの操作を辞めさせることも出来る。
＃これの原理は、配置可能なオブジェクト(Component)のクラスを「事前にコンパイルしDelphiに登録しとく」という
＃平凡なやり方です。そしてそのクラスのインスタンスを「設計」画面では(実行時と同様に)実際に生成し配置する。
＃＃「実行」モードに移る(というかEXEを起動する)時には、設計画面のImageファイルみたいなものを生成し、それをEXEに読ませる。
＃なので、実行時に起こり得るExceptionは設計時にも起こり得る。望まない参照を蹴ることが出来るのは、ここに由来します。
＃そういえばVCLフレームワークには、参照を切り替えたときや、参照先オブジェクトが消滅したとき(笑)に、呼ばれるメソッドも規定されてます。
＃＃DelphiはGCが無く、参照してる限り相手は消えないという世界ではナイです。なので逆に、消えちゃったら消えたなりの対処をするチャンスが用意されてる。

なお、実際にモードなる概念を明確に取り入れる必要が有るかどうかは別問題ですし
(Smalltalkみたいな考え方をするなら、この程度の事でわざわざモードを分ける必要なんか無い、とも言えそうです。)、
有ったとしてもそれが、システム全体が同時にモードを切り替えるのか、それとも
ある相互関係に関わってるオブジェクトだけが切り替わればいいのか、も別問題です。

なんにせよとにかく、self(から|へ)の配線について、self自体が「五月蝿いことを言う」機会が
あればいいんです。「こんな配線食えるか！」とか「俺の相棒をどこやった？」とか。 --戯


具体的な例だと…

仮に…

setter以外の全てのメソッドには引数が無く、
getter以外の全てのメソッドには返値が無い、

というのを強制したら、どうだろうか？ --戯

たとえば、3 + 4 を例に、配線パラダイムを語っていただけるとイメージしやすいのですが。
+ という関数（オブジェクト）が 3 と 4、そして答えの 7 というオブジェクトに配線で繋がっているイメージで合っていますか？--sumim

3+4じゃ無理ですね。

整数みたいに、同値な変数が実はシステムグローバルで同一な奴を使いまわされてる、
なんてな恐れ(^^;が強いタイプのオブジェクトは、配線を適用しても全然綺麗にならないので。

だって、見え難い個所で配線の数が爆発しちゃうのがオチだから。

あと、たとえば電子に配線する(という設計を選択する)のは馬鹿でしょう。電子はむしろ電線の中を流れるもの。

さすがに何でも配線すれば綺麗になるとまでは言えないです。

数や文字列みたいな奴らは、それ自体に配線をかますのは不似合いでしょうね。
MVCのMとしてStringやIntegerをそのまま使うことって、滅多に無いと思いますが、それと似たようなもの。

ただ、StringやInteger「の器」を用意することは、しばしば有ると思います。
そいつにならば配線してもいいかも。 --戯

では器と考えて分数ではだめでしょうか？
分数 (3/4) は属性 numerator に 3 を、denominator に 4 を配線しています。
同じく分数 (4/5) は numerator に 4 を、denominator に 5 が配線されています。
ここで、両者の和、(3/4) + (4/5) は、関数 + に (3/4)、(4/5) が配線されているとして、
答えの (31/20) への配線は誰がどうした過程で行なうのか、ちょっとイメージできかねています。
そもそもマグニチュードや計算を例にするのがイカンのでしょうか？
効率や美しさはこの場合、無視していただいてもよいと思うのですが。--sumim

>4 を配線しています。

なんか駄目っぽく感じます。 4「を」配線するなんて、無茶です。

リアルワールドに「4」という物体(笑…えてしまうところが問題なわけで)が有ったとして、
そこにケーブルを繋ぎたいか？と問われると、少なくとも俺は繋ぎたくないです。

ケーブルを繋ぎたくなるよーなもの、に繋ぎたいです。

あと、

>関数 + に (3/4)、(4/5) が配線されているとして、

関数ごとき(笑)に配線様を繋ぐのも、俺的には駄目。
だって関数は、(小賢しい瑣末な実装をどうするかっていう問題はさておき、もともとの意味としては)
「もの(オブジェクト)」じゃないから。

オブジェクト様どうしを繋ぐんすよ。

>そもそもマグニチュードや計算を例にするのがイカンのでしょうか？

イカンと思います。

MVCを例に出したけど、MVCでいうModelやGUI部品は「もの」としてイイカンジだと感じませんか？
ああいうカンジのするものだけが、配線モデル(のNode)に似合うんだと思います。

immutableなもの(整数とか)や、mutableだと捉えることに意味が無さそうなもの
(たぶん分数はそうでしょう。分子や分母が入れ替わったら、それはもう「別のオブジェクト」と捉えるほうが良いと俺は思う。)は、
配線してもしょーがないでしょうね。
配線で繋がった(少なくとも一方の)オブジェクトの状態が変わるところが味噌というか、
むしろ、その変わり方が、通常の運用だと激烈すぎて手におえない(^^;ので、
配線モデルによって変わり方に程よく足枷をかけたい、という願いが有るので。 --戯

加算器は3と4というオブジェクトに繋がっているわけではなく、
配線された他オブジェクトから3,4というデータが流れてくるんですよ。

加算器は2つの入力ポートと1つの出力ポートを持っている。
で、他のオブジェクトの出力ポートから自身の入力ポートに3が、
もう一方に4が入力されていれば、7という値が出力ポートに現れる。
加算器にとって誰から受け取って誰に吐き出すかは問題ではなく、
それを知る必要も無い。
何を受け取って、どう処理して、何を吐き出すかが全てになる。
他のオブジェクトと配線するのは加算器の外側に責任があると。

実際のプログラムにおいては、+演算子の数だけインスタンスがあって、
演算子の部分で配線が行なわれている形になるんでしょう。 --yasozumi


なるほど。
加算器は、加算(関数)をラップした箱なのでしょうね。


Max の/が 例

Max説明ページのhttp://chiba.cool.ne.jp/kestner_2002/comp/pddoc/02.htmにあるような、

>「float」の仕事とは、数の記憶装置って感じですかね。

みたいな位置付けのオブジェクトは、配線をつけるのに値するオブジェクトだと思います。
数みたいな値オブジェクトそのものじゃなく、値オブジェクトの(なんらかの意味での)器。 --戯

ちょっとズルイけど強引に「既存の例」と見なせるのが、Maxかも。 --戯

あと、CyberFrameworkって関係あるかな？



MVC でなぞらえると…

だいたい粒度がつかめてきました。
そうすると、Smalltalk の MVC に何を足したらいいのか…という話なら
モデルの有効性の検証に耐えられそうですね。

Smalltalk の MVC はすでに“IC”たちが属性を介してとりあえずは繋がっている状態にありますが、
しかしこれらの“配線”は繋ぐ側と繋がれる側が存在し両端が等価でないという問題がありそうです。
配線なら、同じ“導線”で繋がっていて、どちらからも“たぐれる”のが普通ですからね。
ここいらへんに不満があるという解釈は合っていますか？

他方、各オブジェクトの役割りに関してはもっと配線とはほど遠い状態にありあそうです。
たとえば、考えているオブジェクト群が文字列エディタのようなもので、
編集中の view の文字列を model のそれに一致させる「保存ボタン」のようなものを考えます。
このボタンが押されると、その controller は model に対し、
あらかじめ model と示し合わせたセレクタ（たとえば #acceptContent:）に
自ら保持している文字列をパラメータとして添えてメッセージ作り、それを model に送信します。
model 受け取ったメッセージから自分の文字列を更新し、
自分と繋がっている view に対して、自らに変更があったことを #changed で知らせます。

これの挙動は確かに刹那的で、配線といえるものではありません。
配線の候補としては、
といったところでしょうか。こういう方向性で合っていますか？--sumim

>どちらからも“たぐれる”のが普通ですからね。
>ここいらへんに不満があるという解釈は合っていますか？

不満有りという意味では合っていますが、優先度は2番目ってとこです。
1番の要求は、(現状に近いという意味で)片道で我慢していいから、とにかく繋ぎたい。

なお、両方向性についての一実装案は、俺は既に"経験"してます。戯/俺の某…ごにょごにょ…

あと余談ですが、UMLでは、デフォルトでは (つまり矢印の形状で殊更に方向を指定しない限り)
参照は両方向です。
で、矢印を書いてない状態のクラス図(等)が表現するモノを、たいした手間もかけずに素直に実装できる言語は、
実は滅多に無いみたいです。少なくともメジャーな奴には。
少なくとも、UMLとJavaが相性が良いなんてのは、そういう意味では凄く嘘です。自然に表現できる概念の範囲の隔たりが、かなり大きい。
「参照」なんていう有り触れた概念ですら、UMLとJava(などの巷の多くの言語)とではモデルが違う、ってのは、ちょっとショックです。

>保存ボタンと保存というロール、保存というロールと model への結線。

そうですね。あまり細かくは考えてなかったです(^^;が、そういうのが有力な一案だと感じます。

ところで偶然ですが、コンポーネントという単語を思い出しました。というのは、
○Delphi用語でいうコンポーネントの「イベントプロシジャ(またはメソッドポインタ)」の概念が、上記に似てるっぽい。
少なくとも対象InstanceとMethod名(?)をいっぺんに指定できる。引数なしメソッドへのメソッドポインタは「配線」にかなり似て見えるかも。
○UML2.0の新しい(従来とは全然違う)コンポーネントなる概念には、「ポート」とかいう端子みたいなものが付く、とか何処かで聞いた気がする。
あと、チュッパチャプス飴(^^;みたいな奴と、その飴に嵌まるお椀みたいな奴と、が有るそうで、これが「配線」と似た概念かも知れない。
と、偶然ですが2つのHITが(俺記憶的に)あったもんで。 --戯


引数を例に出したのがまずかったのでは？

「関数の引数」を引き合いに出したのがまずかったのでは？＞戯
なぜって、一つの関数は（君が別のところで言っていたように）「複数の”箇所”」から呼ばれる可能性がある（可能性を否定and/or拒絶できない）から。
結局、「関数もクラスさ。関数のコールは関数インスタンスを一つ作るのと等価さ」と言わないと始まらない。
なんだ、関数なんかいらないじゃん、オブジェクトでいいじゃん。という話になって、有野氏に「それってプロトじゃん」とか言われるのかもしれないが（笑）。--CUE

>「関数の引数」を引き合いに出したのがまずかったのでは？＞戯

どうだろう？「関数の引数に値をbindすること」とでも言い換えればいいかな？これなら関数インスタンス(^^;を語ったことになる。

>結局、「関数もクラスさ。関数のコールは関数インスタンスを一つ作るのと等価さ」と言わないと始まらない。

始まるっつーか、その議論は俺としては 戯/六本松 のコンセプトを語った時点で、語り尽くしてる(=終わってる話題だ)しなあ。
つまり、「既に(このSwikiサイトでは)言っている」んで。
＃このSwikiサイトというオブジェクトの属性として既に参照済みだ。引数としてここで刹那的に語る必要は無い(藁

>オブジェクトでいいじゃん。という話になって、有野氏に「それってプロトじゃん」とか言われるのかもしれないが（笑）。


で「プロト不要じゃん」と言われるわけね。

そういや有野氏は関数化も(場合によっては)嫌いみたいなことを言ってたような？？
なるほど。プロトも関数も不要だ、と。整合性のとれたスタンスだ(藁 --戯

関数のインスタンスを一つつくるのと、関数クラスのインスタンスを一つつくるのとは、等価じゃないと思ってたが？＞六本松。
つまり、六本松には、そもそも引数という概念はないわけで。したがって、厳密な意味で関数もない：なぜなら、関数の「ある状態（を表す概念、端的に言えば「継続」か？）」がない（と思われる）から。ある瞬間の関数オブジェクトは、関数のその瞬間の状態を表しているわけじゃないだろう？
少なくとも俺はそう思ったが。
で、関数のインスタンスというのは、引数を初期条件として、関数のある瞬間の状態を表しているものであると考えていいと思う：適当なところで止めて、また好きな時に再開できる。六本松では、それを表す概念がないと見たが、いかが。
…そういう言語があったよな。名前は忘れたけど、関数がファーストクラスの言語。
returnの変わりにsuspendで、関数のその瞬間の状態を保持したまま値を返し、ふたたびコールされた時はsuspendした状態から再開する、っていう。
（なんか、配線と関係ない話になってしまったが…）--CUE

ちょい考えた。

>「複数の”箇所”」から呼ばれる可能性がある（可能性を否定and/or拒絶できない）から。

うん。それがまさに「むかつく」点。
やりたいのは例えば、「或るオブジェクト(インスタンス)」の或るメソッドの或る引数として渡せる「オブジェクト(インスタンス)」を、
予測可能な限られたもの(典型的には1つ)だけに限りたい、ということなので。

つまり、呼ばれを拒絶する(or受け入れる)のを制御する単位として、インスタンス(あるいはロールかも知れないが)を活用したいんよ。

こっちの電球ソケットのスイッチを捻ったらあっちの電球が点灯した、じゃ困るんよ。それじゃ漏電じゃん(違
こっちの電球ソケットのスイッチを捻ったらこっちの電球が点灯してほしい。
この「インスタンス単位の繋がりさ＆繋がってなさ」を表現したい。

電線は、確かに電気ならば何でも通せるだろう。
が、実際に使うとき、それだけじゃ何の価値も無い。
具体的な特定の2点間の配線として使われることで、その2点間に電流を流し、
かつ暗黙的(?)に、「その2点以外の通電(漏電かも知れない？)を支援しない」、
ということによって初めて、価値を成す。

そうすれば、逆に通電を切りたければ、「その」電線をちょん切れば済む、という事になる。＃こういうのが「メンテナンス性が良い」と言えると俺は思う。
「繋ぐことが出来る」という点(=型?)しか論じなければ、
この「ちょん切る」ということが出来なくなるんだよね。＃上記の「拒絶できない」と恐らく同じ意味。

で、それとあと、正に流れてる瞬間(刹那)だけじゃなく、どこに流れるかを
事前(ここを流れるはずだ)に判り易くしたいし、事後(ここを流れたはずだ)にも知りやすくしたい。
それが配線。 --戯

普通の関数呼び出しの歳に、引数を入れ替えたくなる時がたまにある：
例えば、
hogehoge( a, b );
というのを、適当な条件で、
hogehoge( b, a );
にしたい時。
通常、
if (適当条件) then hogehoge( b, a ) else hogehoge( a, b );
みたいにするわけだけど、例えばこれを、
hogehoge{ if (適当条件) then ( b, a ) else ( a, b ) };
みたいにできるといいなと思ったりする事もある（無論、そういう書き方ができる言語も存在するわけだが）。
まぁ、実際には、
hogehoge( a, b, 適当条件 );
のようにhogehoge()の方を書き換える事になるのだとは思うが、プログラムのニュアンスは大分変わってしまう。--CUE


h=hogehoge;
if (適当条件) then h( b, a ) else h( a, b );

とか… --戯

なんかHashed某みたいだけど、良いのか悪いのか良く分からない。それは置いといて…
戯の言っている事は、プログラミングを考察する上での一つのスキーム（パラダイムではなく）を提案しているのだと思うのだけど、関数と引数という例で、配線の必要性を説くようなアプローチが正しいとは思えないんだけどなぁ。
例えば、上で戯が（何気なく？）書いた「h」だ。この「h」って、何よ。って話。--CUE

>関数と引数という例で、配線の必要性を説くようなアプローチが正しいとは思えないんだけどなぁ。

いや、だから、乱暴にいえばこれは引数有害論(笑)なわけよ。
引数捨てて配線にしようぜ、と。

引数は、反面教師として引き合いに出したつもり。

>例えば、上で戯が（何気なく？）書いた「h」だ。この「h」って、何よ。

h云々は、配線つーか引数有害論とは「無関係」だと俺は思って書いた。
＃てか、なんでこんな所に書いてんだ？と思ったり…

引数を入れ替えたいというニーズ(だよな?)は、
配線論とはあんまり重なる(あるいは反発する)部分が無いように思えたので。

ただ、六本松(岩田)を引き合いに出すまでもなく、
(関数インスタンスの)引数とローカル変数とついでに普通の意味でのオブジェクトの属性との三者は結局地続きなので、
同じ悩みが全く無いと言ってしまうと嘘になる。
つまり配線の入れ替えと引数の入れ替えは似た問題なのは確か。

まあ、配線(や引数)の「入れ替え器」を挟めばいいんだけど、
その入れ替え器が多くなればなるほど、プログラムは(人間に)判りにくくなるんだろうと思う。--戯

まさにそこだ。
ハードウェアにおける配線も、「マルチプレクサ」や「レフレックス」と言った作用のために、君が口で言っているほどには単純じゃないわけだ。
上に何気なく書かれた「h=hogehoge;」についても、一見当たり前のように見えて、実は意味論上のいろいろな問題を抱えているように思える。--CUE

>口で言っているほどには単純じゃない

ものごとをより単純に見る見方の見本として「配線」を挙げたけど、
電子回路全てが(現行の有りがちなソフトウェアより)単純だ、とまで言ったつもりは無い(だよね？)わけで、
電気の流儀に「全て」倣ったら「全て」単純になる、とまでは言えないのはまあ確かで。

単純な配線(に喩えられ得るもの)で済む部分すら、複雑なデバイス(に喩えられ得るもの)のように記述してしまってる個所が有ったら、
それは寒いよね、という話。

で、どうもその寒い状況が(のほうがむしろ)凄く多いのではないか？という心配。
＃てか、今まさに辛いんだけどさ俺(^^; --戯

あー。
単純素朴な配線の数を増やす、逆に複雑(だよな)なデバイスの使用頻度を減らす、っていう考え方を、
設計の方針てか指標の1つとして持っておくと良い、んじゃないかと思ったんだ。

>スキーム

アーキテクチャパターンの一種かも、とは昨夜少し思った。--戯

Martin Fowler's Bliki クラス図におけるローカル変数


相手を「予約」する感覚

配線はインタラクションの相手を「予約」する物である、っていう感覚かな。
インタラクションってのは、メソッドの引数(ここではレシーバも含むとする)並びに
居並ぶオブジェクトたちの間で交わされるわけだけど、
その組み合わせがメソッドが呼ばれるまで判らない、ということにしたくない。

雷みたいに(^^;実際に稲妻が飛ぶ瞬間まで何処に飛ぶか判らないのが、引数方式(の問題点)。
避雷針を用意したい。いや、もっとしっかりと結線してしまいたい。

SEGA Dreamcastのゲームで、DreamStudioなるものを、先日中古で購入した。今は、Windows版も出ている。いわゆる”ＲＰＧツクール”系のソフト。
3D歩き回り系のゲームが好きなので購入したのだけど、これのシナリオ作成方法が、なかなか笑える。
ある一定のアクション（＝プレーヤーへの問い合わせ）やイベント（＝劇）や条件（＝トリガー）を表す「箱」の間を「線」で結ぶ、というもの。
どこが笑えるかというと、事実上、箱ではなく線が状態を保持しているところ。
箱の方も状態はあるにはある（ＯＮとＯＦＦ）んだけど、その状態がリアルタイムに次の箱に伝えられるわけじゃなく、線がその「状態の変化」だけを受け取って保持する。
…一見、箱だけがオブジェクトのようで、実は線もオブジェクトだった、というお話。--CUE

関係ありそうなキーワード？： selected export


MVC に見る「配線」

ところで、たとえばMVCは、配線こそ成されていないものの、結果的にはそれに近い効果を挙げていると思います。

配線ではないんだけど、1つの基板みたいな感じかな。
それにMとVとCが載っていて、その基板単位を部品として扱える、みたいな。
電球のすぐ後ろに、気の利いた小さな回路が載ってる基板がついてる、みたいな。

＃ただし、その基板の「外」への配線という問題は、依然残りますが。

なお、対応するオブジェクト同士じゃなく画面という大きな単位でしか基板(?)が用意されていないという意味で、
近年言われるwebアプリでのMVCってのは、エセだと感じます。
だいたい表示系とデータ系を分けるなんてのはOOP以前から行われていたことで、
それをオブジェクト単位でやらないのならば、MVCなんて呼ぶ意味が無いんとちゃうか？と小一時間…。
まして、画面に合わせてデータオブジェクト構造を用意するなんて、本末転倒。

Smalltalk（VisualWorks）のMVCフレームワークにはすでにソフトウェア配線があると思います。
モデル自体をApplicationModelとDomainModelに分離するというコンセプトになっていて、
前者が上で言う「基板」の役目を果たし、後者がその「外」です。そして
などの各クラスが両者をつなぐ配線なんだと思います。（もっと詳しく調べないと、それぞれの位置付けとか使いどころをまだよく理解していないのですが）--SHIMADA

ソフトウェア配線は、 Dependency Injection に似ている…でしょうか？

配線という考え方を実際のICの配線と対応づけて考えてみました。
デジタルICの場合の配線はあるICの出力から出てきた信号を他のICの（あるいは自身の）入力に伝えるという作用があります。ですから、ソフトウェア部品においても出力と入力の明確な規格が必要になると考えています。で、私が考えるに出力に相当するのが"Java"で言う所の"event set"で、入力に相当するのが"setter"という事になると思います。そうすると、伝達される信号は"EventObject"の派生オブジェクトで、配線は"EventListener"の派生オブジェクトと対応づけられると思います。
"Java"の場合、"xxxListener"オブジェクトに能動的な動作記述をすることが可能なのですが、これを許してしまうと全体の見通しが悪くなってきます。これは、ICの配線にトランジスタのようなディスクリート部品を接続するのに似ています。論理が反転しているとか同期しているクロックが異なるなどの、どうしても仕方のない時には、この"Listener"を"Adapter"と呼ぶことにして入出力を整合させれば良いでしょう。
ちなみに、デジタル信号でも双方向の信号は考えてはいけなくて、互いに折り合いをつけて動作するアナログ信号も双方向信号のたぐいであろうと考えます。 -- noritan



このページを編集 (27569 bytes)

Congratulations! 以下の 8 ページから参照されています。

This page has been visited 7970 times.