OOP

素朴な疑問...
えっそうですか？...
Re: 素朴な疑問...
変数って、関連なんですよね...
束縛、環境...
Smalltalkにおいては...
コンテナクラスについて...
オブジェクト指向のWeb-Server...
Lispでオブジェクト指向...
CompositePatternの親子関係を複数化する問題...
デザインパターンを云々するのは抽象化が足りないから...
あったあった...
関連が記述できないのは抽象度(の高低)の問題では無さそう...
not Java vs UML...
振る舞いに関するひな型 behavior なんていうものを考えてみるテスト...
パターン(名)を振る舞い(名)で識別するの？...
もちろん「振る舞いに関するパターン（名）を識別する」です。...
interdependanceとか？...
object``s''指向、とか(ぉ...
個人的には、relationは、ちょっと抵抗が(^^;...
軍師(参謀)指向...
コンポジットパターン...
CompositePattern「が」再帰手続を担当するわけではない...
逆にいえばLisp方式は...

素朴な疑問

「すべてがオブジェクト」であると純粋性を謳うオブジェクト指向なプログラミング言語はいくつかあるけど、そういう言語でも変数だけはオブジェクトではない。なぜ？

[[id:827]] 2002-07-02 13:06:59

えっそうですか？

変数(が示すもの)がオブジェクトでなかったら何がオブジェクトなのでしょう？

----
「変数」と「変数が示すもの」とは同じものではない、というのが元の質問の趣旨というか前提なのだと推察します。-戯

----
ちなむと、変数すらObjectになっている言語としては、PostScriptなんかが近いかなという気がします。

明示的に作成した辞書Objectに、SymbolObjectを突っ込むことで、普通の言語でいう変数のようなものを
実現しているわけですが、あれなんかまさにそういう感じ。

3 dict %(容量3件の)辞書Object作成してoperand stackに積む
begin %operand stack topの辞書Objectをカレント辞書にする(=辞書Stackに積む)
/hoge 1 def %辞書stack topの辞書Objectに、"hoge"=1 というname-value pairを登録する
hoge %辞書stack topの辞書Objectを"hoge"で検索し、得られたもの(ここでは1だろう)をoperand stackに積み、
== %上の結果(operand stack top)を、なんかする。たとえばここではputs()。
end %辞書Stackを1つpop(そして破棄)する

変数って何だ？と問われると、言語によって色々なわけですが、
たとえば上記のようにPSでは、辞書Objectに記録されたnameである、ということになるわけです。
#なのでPSのscope(?)は動的です。

あ。Lispももしかして似てるんでしょうか？

[[id:828]] 2002-07-02 14:55:50

Re: 素朴な疑問

「オブジェクトではない」(素朴な疑問 (#1))とは、変数自身にメッセージを送ることができない。変数の定義がメッセージ送信の形態をとらない。…という意味ですか？　--sumim

- 端的に言うと "Variable" みたいなクラスがないのはなぜだろう、「すべて」から除外されているのは何か理由があるのだろうか、ということですね。
- ただ「変数もオブジェクト」という言語があったとしても、それはどうやって記述し動作するのか想像できませんが。
-「コンテナ」クラスじゃだめ？？

[[id:829]] 2002-07-02 18:16:41

変数って、関連なんですよね

ま、考え方はいろいろあるけど、その一例を。

ある環境(例えばPostScriptでは個々の辞書Object)における、名(PSではSymbol)が、変数であるわけです。

これって、環境と名との「関連」であって、それ自体がなにか1つのモノ(=Object)なのか？と問われると、
ちょっと一休さんの「拍手はどっちの手が鳴ったのか」問題に近いものを感じるっす。 -戯

答え：左右の手の、「たたき合わせた」という名の関連が、鳴っています。

----
尤も、関連というものを、独立したObjectとして扱うというOOPアーキテクチャも、有るんだけどね。
上記の拍手の例でいえば、その瞬間、左右の掌の間に、「叩き合わされたぞ繋がり」クラスのObject(^^;が
生成され、こいつが音を鳴らし、直後にGC(^^;される、という感じかな。
そういうアーキテクチャなら、変数「に」何か命令(message)を投げる、ということもありえるかも。

----
あと蛇足だけど、C言語のポインタは、変数Objectの代用品として使われることが、多いですね。
ある環境の中でのその名が指す実質領域を指すことで、変数そのものの代用としているわけで。

[[id:830]] 2002-07-02 15:04:17

束縛、環境

変数って、関連なんですよね (#4)
その「関連」はLisp方面では束縛と呼んでいますね。
そして、コードのある時点で見える「束縛」の集合が「環境」。
「環境」には以下のメソッドが定義されていると。

lookup env, name -> value
update env, name, value -> ()

「環境」を明示的にオブジェクトとして扱える処理系もあります。そうでない処理系では変数参照、代入時にこれらのメソッドが暗黙に呼ばれているということでしょう。

では「束縛」をオブジェクトとして扱うものはあるか、というと、次の論文における"first-class extent" が近いかなあ、という気がします。
Shinn-Der Lee and Daniel P. Friedman, First-class Extents,
ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/iucstr350.ps.gz

[[id:831]] 2002-07-02 15:47:20

Smalltalkにおいては

グローバル変数は SystemDictionary というクラスのオブジェクトに発信されるメッセージの一種と考えられますよね。
束縛、環境 (#5) でいう暗黙のオブジェクトとしての env と違う点は、入れ子にならないというところでしょうか。
なぜ入れ子にならないかというのも考えていくと興味深いですね。

じゃあSmalltalkでのローカル変数は？というとなんなんだろう。SystemDictionary が入れ子になるというモデルだったならローカル変数も↑と同じことになるんだけど。

そういえばワークスペースでは宣言のないローカル変数をサポートする代わりにワークスペース自身がつかんでしまって明示的な解放が必要だみたいな話がsmlで指摘されてましたね。

[[id:832]] 2002-07-03 09:00:24

コンテナクラスについて

Re: 素朴な疑問 (#3)

俗(?)にコンテナクラスといえば、配列クラスとか辞書クラスとかSetとか、そういう感じのものを指しますね。
一方、俗じゃないけど、変数クラス(?)をそう呼ぶことも、まぁ出来ないわけではないかも知れない。

で、両者の共通点なのですが、変数も配列も「他のObject(の参照かも知れない)を持つもの」だったりする。 -戯

[[id:836]] 2002-07-03 20:01:54

オブジェクト指向のWeb-Server

- Zope
-- http://www.zope.jp/
- Comanche
-- http://minnow.cc.gatech.edu/swiki/6
- cl-http
-- http://www.ai.mit.edu/projects/iiip/doc/cl-http

[[id:850]] 2002-07-06 22:42:34

Lispでオブジェクト指向

オブジェクト指向のための標準的？ライブラリってあるのかな？

- CLOS, Stklos系
--CLOS (Common Lisp Object System) (プログラミング言語:Lisp)を参照のこと
-- GOOPS (Scheme) http://www.gnu.org/software/goops/goops.html

[[id:886]] 2002-07-17 13:00:20

CompositePatternの親子関係を複数化する問題

これでしばしば困るんですよね。

CompositePatternはObjectの親子関係を表現できる。ここまではいいんですが、問題は、
親子関係のようなものを「(1つのObjectの中で)複数」持たせたくなったら、
とたんにおかしなことになる、という点でして。

ちと架空言語で戯画的に表現しちゃいますが、

interface 親{}
interface 子{}

interface 実の親 extends 親{}
interface 実の子 extends 子{}

interface 師匠 extends 親{}
interface 弟子 extends 子{}

class 人 implements 実の親,実の子,師匠,弟子{}
//人は、誰かの実の親や師匠に、将来成るかも知れないもんね。

ここで、肉親関係も師弟関係も、ほぼ同じ「親子関係」という仕組みを継承してるであろうはずなのに、
上記の人クラスを作ると、JavaはもちろんJava以外でも(例えばJavaのinterfaceじゃなくrubyのmoduleで
実装多重継承をしようとしたとしても：仕組みを共有してるのだから本来はむしろ実装継承のほうが望ましい)
破綻しちまうはずで、

でもそういう構造って頻繁に作りたくなるんだよね、

ってのが問題。
もちろん回避策は幾らでも考えられるんだけど、上記戯画コードをそのまま書くよりは、どれも素直じゃなくなる。

だからインターフェースは後づけ出来るシグニチャのようなのが正しい、
という事ですな:D--有野
----
どうして破綻すると思うのか良くわかりません。親子関係って継承で表現するものなんですか？
もし将来のオブジェクトの振る舞いを変えたいんだったらStrategyパターンの出番であって、
そこでCompositeパターンを持ってくるのは使いどころを間違っていると思います。
----
-「人」に「親子関係になりえる(Parent-Child-ableってのか?英語識者諸兄よろしく)」という仕組みを((多重?)継承で)与えるってのは、変じゃないはずです。
--継承じゃなく委譲にというお題目も有ります(実際それが回避策の最有力候補です)が、それは「素直じゃない」です。
-「振る舞いは」変えたいわけじゃありません。変えたいのは構造、かな。つーか関係を変えたい。
--変えたいものは振る舞いではない、ということが頻繁に生じるのがOOPだと思います。プログラムはRunするものなのか？ (プログラミング)にも通じる。

-シグニチャっすか。
--DelphiのMethodPointer (Delphi)のように「同じシグニチャのMethodPointer」を代入互換にすることが出来るのは、正しいっすね。
--仕事で使ってる某は、message(実はシグニチャ)の宣言という概念があり、かつ既存シグニチャから異名同型を「継承」で生成することも出来ます。結構便利。define instance message Hogehoge(...); define message Fugafufa LIKE Hogehoge;attach Hogehoge to class Foo;attach Fugafuga to class Bar;なんて書ける。
-ただ、それはInterfaceレベルでしか自由に多重化できないんですよね。実装はまさにC++の菱形継承問題を継承(ぉ)しちまって使い物にならない。

-余談だけど、以前から言われてるはずのこととして、継承だけじゃなく委譲も言語BuiltInな仕掛けになってると便利じゃないか？というのが。
--その仕掛けに、ついでに多重化問題を解決する仕掛けを織り込んでおく、と。
--ObjectID自体を詐称し、委譲元Objectであるかのような振りをする、という事が出来る言語だと、楽だろうな。
---そうすれば例えば、「親子関係担当ProxyObject」を2つ「人」にぶら下げて、ProxyはIDを詐称しちまえば、師弟関係も表現できる。

-問題は、肉親親と師匠とをどう区別するか、なんですよね。
--最初の案のような単なる継承だと混線しちまう。
--Proxyの詐称の仕組みを使っても、いったん本体の「人」を経由しちまうと、区別を忘却しちまう。
--getParentメソッドとかを呼ぶときの引数なりなんなりで、「今は師弟関係に注目してるのだ」とかを表す勘合符をやり取りすれば良いんだけど、問題はその勘合符が幾つ必要になるか不明だという点…
---エラー番号いってよし(プログラミング)で出たように、文字列とかクラス(から作られるObject)とかを勘合符にすればいいかな。「親子関係種類表現クラス」が必要かな。
---上記某でも似た仕掛けが有ります。Relationクラスが有り、それの性質(クラス定数)としてRelationshipという概念が有る。これがまた面白いんだ…

[[id:914]] 2002-08-03 16:06:55

デザインパターンを云々するのは抽象化が足りないから

っていうのはどなたのお言葉でしたっけ

OOPの真髄はオブジェクトとオブジェクトのコラボレーションだと思うのですが、現状の主要なOOPLの重大な欠点はコラボレーションを抽象化（取り出して名前をつけたり操作したりできるようにする）する機能がないということですよね。

だからUMLでは記述できる「関連」をJavaやC++でどう記述するんだーと悩んだり、デザパタのように自然言語でふにゃふにゃと論じたりする必要があるのではないかと。

OOP以前の言語で「抽象データ型」が方法論としてが論じられたりしたのと同じですね。
#SHIMADA

-そういやSmalltalk界隈には、ObjectInspector(Delphiみたいな)どころかMVC Inspectorとかいうものまで有るそうですね。これなんかはパターンの言語(?)化の一種かなと。-戯

[[id:960]] 2002-08-09 11:27:31

あったあった

技術野郎の復讐---Revenge of the Nerds---
> コンパイラがやるべきことを人間がシミュレートするという慣行はただ広まっ
> ているというだけでなく、思考を型にはめる作用がある。例えば、OOの世界
> では非常に良く「パターン」というのを耳にするだろう。この「パターン」
> は多くの場合、(c)のケース、すなわち人間コンパイラが実際に動作してい
> る証拠なんじゃないかと私は思う。私が自分のプログラムにパターンを見付
> けたら、それはどこかがおかしいというサインだ。プログラムの形は、それ
> が解くべき問題のみを反映すべきだ。その他の繰り返しがコード中に現れる
> ということは、少なくとも私にとっては、十分な抽象化を行っていないとい
> うことを意味する。大抵の場合、それはマクロを書くべきコードを手で拡張
> して書いているということになる。

最後の部分は「マクロで書くべきコードを手で展開して書いている」かな。

-うねりコードにも通じますね。

[[id:1007]] 2002-08-19 12:17:40

not Java vs UML

Re: 関連が記述できないのは抽象度(の高低)の問題では無さそう (#13)
> 抽象度以外の問題を抽象度の問題にReduceして解くという抽象度低い方法(^^;を採るべきかどうかという新たな問題が…

UMLとJavaの食い違いを解決したいということは考えていません。
両者とも使っていないので困ったことも無いし。:D
というわけで抽象度``が''問題です。

変数 ⇒ 配列 ⇒ レコード ⇒ オブジェクト
と進化(?)してきたんだから、ここでもういっちょ進めたいというだけの話で。

例えば、
「このクラスとこのクラスはこういうやりとりをする。この関係をHOGEHOGEと名づける」
という相互作用を形式的に宣言できて、個々のコードはそれを取り込んで具象化するという、いわばクラスをまたがった interface のようなものが書ければいいのかも知れません。

データ群と手続き群をまとめてオブジェクトにしたように、オブジェクト群をまとめて《なにか》にできればいいんですよね。
クラスにしたまではよかったけど、インヘリタンスはあまり良い解ではなかったみたいだし。
#SHIMADA

----
あ。言語側から見ればべつにJavaのみの問題じゃなく、rubyだろうがなんだろうが、今の「多くのメジャーな」言語は
みんな抱えてる問題なんじゃないですかね。UMLにそのまま相性が合う言語って、偶然出会った某以外には見たことがないような。

RDBと接続したときに意味論インピーダンスミスマッチを引き起こす言語は、みんなこの問題を抱えてます。
(RDBを引き合いに出す理由は前述の通り。)

----
今では大抵、Objectを集めたものを更にObjectだと呼ぶ、という戦略を採るわけです。

で、これをもって、「そんな戦略では抽象度が低い」と貶すべきなのか、それとも、
「これこそObjectがメタ(?)な仕掛けにも十分対応できる証拠だ。Objectまんせー」と誉めるべきなのか、

という点が、難しい問題なような気がします。 -戯

#なにせ、このサイトで大ブレイク中なLisp/FPにも同じ問題が潜在してるはずなのですから(^^;
#関数をまとめたものを関数と呼ぶべきなのか？とかね。
-#つまり、関数「は」抽象度が高いのか？という問題だったりします。たとえば関数やObjectがもし「究極の」抽象度の高さを持っているならば、それをどう料理してもその至高の位置は揺るがず、新たな名を与える必要が無いはずです。
----
デザインパターンを云々するのは抽象化が足りないから (#11)での議論に関数は関係ありません。もとのお言葉もたしかマクロに関する話だったと思います。
マクロはLispに特有なcall by nameによる評価の遅延機能で、他の関数型言語とは関係ありません。

#SHIMADA

[[id:964]] 2002-08-14 12:08:15

振る舞いに関するひな型 behavior なんていうものを考えてみるテスト

「パターンに名前を付けられる」という機能はどうあるべきか。
多分ソースを別に分けたり、独立してコンパイルできたり、
コンパイル後のモジュールを他のソースから利用できたりするんだろう。

----
(MVC.javaの中身)

interfaces MVC {
Model { /* Model に関する interface 宣言 */ }
View { /* View に関する interface 宣言 */ }
Controller { /* Controller に関する interface 宣言 */ }
}

behavior MVC::Model {
/* interface Model に規定されたメソッド・属性のみを使った
Mix-in を記述する */
}

behavior MVC::View {
:
}

behavior MVC::Controller {
:
}

----
(App.javaの中身)

MVC Application {
Model AppModel,
View AppView,
Controller StdController
}

class AppModel uses MVC::Model {
public static void main() {
AppModel application = new AppModel();
:
:
}
/* interface Model を実装する。
上記宣言によって、MVC::Model は Mix-in されている。*/
:
:
}

[[id:977]] 2002-08-14 12:01:30

パターン(名)を振る舞い(名)で識別するの？

れ:振る舞いに関するひな型 behavior なんていうものを考えてみるテスト (#15)

以前も書いたように、パターンにも「振る舞いについてのパターン」とか「構造についてのパターン」とか
色々なパターン大分類(?)が存在するので、
パターンを名づける仕組みとしては、少なくとも、behavior「だけ」だと不味いと思います。

かといって、その仕組みをpatternと名づけてしまうのは明らかに変だし(patternでしかないという状態を我々は脱却したいのだから)。
うーん。なんか良い命名があるといいなあ。

一案：英語でなんと言うかは判らないけど、日本語だと「繋がり(かた)」なんだと思います。

[[id:978]] 2002-08-14 12:55:04

もちろん「振る舞いに関するパターン（名）を識別する」です。

- 生成に関するひな型
- 構造に関するひな型
なんていうのもあっていいと思います。名前はよく考えないとアレですが。

っていうか「ここでは（料理しやすい）振る舞いに関するパターンを例に考えてみよう」という意味をこめて「``振る舞いに関する''ひな型 behavior」と書いたつもりでした。--SHIMADA

----
「○○に関する」の「○○」の部分を、コード上で自分で命名できるようになっていると、いいですね。
-メタクラスならぬメタパターン、か？(^^;

余談：料理しやすいかなあ？構造のほうが与し易いと思うのは俺だけ？

[[id:979]] 2002-08-14 13:15:34

interdependanceとか？

Roleをあらわすinterfaceの組とそれぞれのRoleに関するmix-inという考え方は、特にふるまいに限定しなくてもいいような気がしてきました。--SHIMADA

----
（MVC.javaの中身）

interdependence MVC {
role Model {
/* interface規約とそれに依存する mix-in メソッドを記述。
Model, View, Controller のメソッド・属性どれも使える。*/
}
role View {
:
}
role Controller {
:
}
}
----
（App.javaの中身）
import MVC;

class AppModel uses MVC::Model {
/* uses 宣言によって Model のinterface規約を実装する義務を負い、
Mix-inメソッドの実装を利用する権利を得る。*/
public static void main() {
MVC::Model app = new AppModel();
MVC::View v = new AppView();
MVC::Controller c = new StdController();
:
:
}
}
class AppView uses MVC::View {
:
:
}

----
SHIMADA:
- こういうのをちゃんと整理できれば、インヘリタンスはいらなくなるかも知れないなー。
- "interdependance" だと長いし、思い切って "relation" とか。
- これなら親子であり師弟であるというのも書けるかも。
----
こういうのも「アスペクト指向」の一種らしい。実装も多数あり。 --SHIMADA(2002-09-09)
アスペクト指向言語、Separation of Concerns 関連研究メモ
『プログラムの保守性・再利用性を高めるためには、できるだけ関連の深いコードを近い場所に集めて、他とは分離して記述すべきです。これを separation of concerns （関心事の分離）と言います。

オブジェクト指向言語はデータ構造とそれに深く関連する手続きを１箇所で記述する構文を提供するため、手続き型言語よりも separation of concerns が「うまくできる場合が多く」、そのために広く普及してます。

しかし、一般には複数のクラスを横断する形で関連するコードを記述せざるを得ない場合もあります。つまり、現在のオブジェクト指向言語では、 separation of concerns が「できない場合もある」のです。

この問題の解決のために最近注目されているのがアスペクト指向言語です。（アスペクト指向に関して詳しくは、次の URL を参照下さい。 http://aosd.net）』
⇒ アスペクト指向プログラミング (アスペクト指向プログラミング)

----
-いや、アスペクト指向は、relationを(も)解決する「手段」ではあるけど、そのもの(の一種)ではないと思います。
-アスペクト指向は単にアスペクト(=ものの見かた)という軸でソースを区切る仕組みであって、ではどういう見かたで区切りたいか？はユーザー次第ですよね。
-刺身と包丁の関係かな。アスペクト指向は包丁。relation問題は刺身。なんか違うかも。まぁいいや。 -戯
----
僕の考えたのはクラスとは独立した Role のセットの再利用なので、こちらは Aspect と呼べるような気がします。
#Aspectは「第三の糊」なのかも。--SHIMADA

なんかMJに似てる気が--有野
- そのとおりでございます。（笑　--SHIMADA

[[id:981]] 2002-09-09 18:15:31

object``s''指向、とか(ぉ

[[id:982]] 2002-08-14 16:33:52

個人的には、relationは、ちょっと抵抗が(^^;

Relationという名のClassが存在する系を、いつも使っているものでして。
しかもそれは、
-非常に有用な概念/実装だと思うのだが、C++/Java/Rubyでは実現が困難な、(それらから見れば)特殊なObjectアーキテクチャに基づくClassである
-そのClassにRelationと名づけられているのは、非常に適切な命名だと思える
ので、個人的欲望としては、そいつのRelationクラスという概念を優先させたくて(^^;。

どういうものかというと(って折に触れて既に何度も語っていますが)、
UML1.3以降(だったか)で定義された関連クラスを、まったくそのまま素直に実装できるクラス、です。
こいつが素直に使えるような「クラス」をC++/Java/Rubyで実装するのは、恐らく困難です。

[[id:984]] 2002-08-14 19:50:04

軍師(参謀)指向

能動性という話をするときに若干の混乱が有る(ここでも見られた(^^;)ようなんで。

Threadつーかスケジューラみたいに、ほんとに「それを今やるぞ！」と決断する役割のものと、
決断は自分ではしないが「大将！もしやるならこうすべきだぞ！」と判断する役割のものと、が
計算機の中には居るようだ。(小人さん?)

前者は大将、後者は軍師、みたいなものか。
#するとReceiverは兵隊か？(ぉ

で、Object指向は、判断者の存在をクローズアップした指向であるという意味で、
軍師指向とでも呼ぶべきものっぽいのではないだろうか？(^^;

[[id:1162]] 2002-09-10 22:43:16

コンポジットパターン

うーん、なぜ関数プログラミングは重要か(FP) を読むと「コンポジットパターン」というパターンの存在自体が、非常に重要な何かを見落とした結果ではないか、という気にさせられる。
-上記の解説を乞います(^^;。話が見えない…
-再帰的な構造を扱うのに、再帰的な汎用の高階関数を作って組み合わせる、という発想が CompositPattern の中に見出せないので、どうしてなんだろう、なんか変だぞ、と直観的に思うわけです。直観なのでうまく説明できないのですが。
----
＞汎用の高階関数

ん？有りますよ？憂鬱本のP172の、集約について解説しているところで、

＞同じ操作が集約先のクラス(戯注：Objectの誤記だろう)まで順順に伝わっていくのが「伝搬」です。

というのが出てきます。集約といえばCompositePatternなわけでして、
この伝搬ってのが再帰呼び出しを意味しています。いるはずです。

で、再帰はともかく、高階関数である必要は、有るんですか？

というか例えばオブジェクトを「シンボルを引数に取る関数」ととらえて見ると (クロージャとオブジェクト)的に解釈すれば、なんらかのMethodに引数としてObjectを渡すことは
関数(しかも状態つき)を渡してることに相当するわけで、OOPは最初から高階関数使われまくりだ、
と言ってもヨイのではないかと。 -戯

ってゆー話っすか？
読み違えだったらご免。それともCompositePatternの親子関係を複数化する問題 (#10)系の話でしょうか？

----
なんか上の段落は禿げしく間違えてるっぽいですんで再考します↑-戯

「なにを」伝搬するかを抽象化というか外注(^^;化したいよね、という問題かなー。
----
あ、wiliki:Scheme:オブジェクト指向表現の後半にすでに議論されてますね。

おそらく、継承よりも修飾のほうが柔軟で使いやすい（＝部品としてのモジュラリティが高い）という話に通じるんじゃないでしょうか。あと差分ベースモジュールとか。

[[id:1283]] 2002-09-24 18:02:37

CompositePattern「が」再帰手続を担当するわけではない

コンポジットパターン(#22)
>再帰的な構造を扱うのに、再帰的な汎用の高階関数を作って組み合わせる、という発想が CompositPattern の中に見出せない

思うに。 -戯
構造が再帰であることと、その再帰構造に「沿った岸辺(?)に」手続を適用しまくることとは、
必ず抱き合わせするべきものなのか？という問題があるのではないかと。

GoFデザパタ的にいえばたぶん(俺はろくに理解してないので)、
再帰構造自体をCompositePatternがサポートする一方で、
その構造を手繰りつつ手続きを適用するという流れ(?)は、
VisitorPatternとかの別のパターンが担当することなのではないかと。

#注：ある1つのObject郡の中に「同時に」複数のパターンが見出せる(適用できる)ことは、茶飯事です。
#パターンを同時に組み合わせちゃいけないという法は無い。甘辛煮は立派な料理です(ぉ

GoFパターンsは、「構造のためのパターン」とか「振る舞いのためのパターン」とか分類されますものね。

構造を表現するパターンのうち1つの著名なものがたまたまComposite(=入れ子)Patternだ、というだけでしょうね。
一方で、(どんな構造かはさておきとにかく)構造を手繰ってチョメチョメするほうがVisitorなわけで。

[[id:945]] 2002-09-24 18:24:50

逆にいえばLisp方式は

CompositePattern「が」再帰手続を担当するわけではない(#23) の続き

その中で構造を司ってるパターンが、いわばLinkedListPattern(^^;;;;なのではないかと。
その構造がとにもかくにも必ず(?)存在するという前提で、それに対してVisitorPatternを使うのが、
くだんの[[高階関数]]の説明だったのではないかと。
(それが[[高階関数]]の全てだとは言いません。あそこで紹介された事例はそうだったというだけで。)

あの説明だと、「構造手繰り屋」が高階関数になっており、その手繰り屋に身を任せるVisitorが addとかの
高階され(?)関数であるように見えます。

で、メソッド呼び出しが関数のシンボル引数つきCallだというならば(^^;、逆にいえば
ObjectのMemberに他のObjectを与えるのは、FunctionのArgに他のFunctionを与えるのと同じであるはずなので、
Visitorがやってることは高階関数そのものであるのだろうな、と。

蛇足：StrategyPatternとかも。てゆーか「振る舞いのためのパターン」の多くがコレだろうな。

#ただいまW3Mで書いてます。書きながら他の頁/Paragraphを参照できないのがW3Mの痛いところ。
#というわけでとりあえず他のParagraphの正確なLocationを失念した状態でとりあえず書いてます。
#あとで適宜、参照すべきParagraphを見つけておきます。

[[id:1285]] 2002-09-24 18:25:11

top recent

HashedWiki version 3 beta
SHIMADA Keiki

OOP

目次