- PR -

.NET開発者のためのリファクタリング入門について

参照元記事 | 同じ記事を参照しているスレッド一覧
«前のページへ 1|2|3|4|5 次のページへ»
投稿者投稿内容
コモンセンス
会議室デビュー日: 2005/01/05
投稿数: 15
投稿日時: 2005-01-05 12:22
objectさんが書かれたことにほとんど同意です。

objectさんの書き込み (2005-01-01 14:02):
>私は、今の「ソフトウエア科学」はある種の「ドグマ」に陥っていると思っています。
というより、「いまだ哲学的基礎があやふや」と言うべきではないでしょうか?

>以上の要約を述べると、
>「プロパティ」->「フィールド・ファンクション」で記述
>「メソッド」->「フィールド・ファンクション」で記述
>#詰まり、
>#「フィールド・ファンクション」は「実装概念」と言っても良いと思います。
Yesですが、さらにいうと、「メソッド」もモデリング概念としては未成熟と
思います。いずれ除外あるいは変更を迫られると思います。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2005-01-05 14:12
objectです。

>コモンセンスさん
>>私は、今の「ソフトウエア科学」はある種の「ドグマ」に陥っていると思っています。
>というより、「いまだ哲学的基礎があやふや」と言うべきではないでしょうか?
私も、「ある意味」では「哲学的基礎があやふや」であると思っています。

ここで、私が書いた「ドグマ」は、
「哲学的基礎があやふや」
であると
気付く事に対する「閾」として「無意識」の内に働いている「断定・慣習」を指した言葉
です。
#「UML」だけで無く、「Java」の「かなりの有名人」でさえも
#「この事に気付いていない」
#と私は感じています。

従って、
この「閾」を「意識下」にあげる事が「先ず重要である」と私は思っています。

それから、
「形式論理学」と「記号論理学」の経緯を考えても
「表現」の重要性がとても大きい
と私は思っています。

そういう意味では、
「哲学的基礎があやふや」
というより
「数学(論理)的基礎があやふや」
と言って良いのではないでしょうか？
#「自然言語」による「抽象化」には「限界」がある。

>Yesですが、さらにいうと、「メソッド」もモデリング概念としては未成熟と
>思います。いずれ除外あるいは変更を迫られると思います。
勿論、「プロパティ・メソッド」は「対概念」ですから、
「プロパティ」での問題を「メソッド」で「カバー」 -> 「メソッド」も歪んでいる
という事だと思います。
コモンセンス
会議室デビュー日: 2005/01/05
投稿数: 15
投稿日時: 2005-01-05 14:49
コモンセンスです。

objectさんの書き込み (2005-01-05 14:12) より:
>「表現」の重要性がとても大きい
同意です。

>「哲学的基礎があやふや」
>というより
>「数学(論理)的基礎があやふや」
>と言って良いのではないでしょうか？
はい、その方がずっと適切と思います。

>勿論、「プロパティ・メソッド」は「対概念」ですから、…
「メソッド」は実装概念ではないでしょうか?
論理概念として一級の座位を与えることは
できないと思います。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2005-01-05 18:46
objectです。

>コモンセンスさん
>「メソッド」は実装概念ではないでしょうか?
>論理概念として一級の座位を与えることは
>できないと思います。
どの様な根拠で
「メソッド」が「実装概念」になる
のでしょうか？

そしてまた、どの様な理由で
「論理概念として一級の座位を与えることはできない」
という事になるのでしょうか？

菊池
会議室デビュー日: 2004/11/15
投稿数: 19
投稿日時: 2005-01-05 22:49
>どの様な根拠で
>「メソッド」が「実装概念」になる
>のでしょうか？

　データの存在が必要という論理概念は呼びの方向は意識しない事もできる。

　取り出すというメソッド呼び出し
　or
　アクティブオブジェクトとかから呼びが出てきて渡される

　それがどっちかに限定されるから実装概念だという事かなと私は
思いましたが、コモンセンスさんの意図は違うかもしれません。

　しかし、何が論理概念で何が実装概念であるかなんて議論は閾値
とする抽象度の設定次第でいくらでも結論が変わる事です。
　どっちも論理概念であり実装概念だと思いますよ。
　完全な実装概念は実行可能なバイナリですし、完全な抽象度を
もったら「★！＃（意味不明）」だけでも論理設計終了です。

　抽象度をどの程度に設定するのか同意がなくては議論が成立しない
のではないかと、話の流れを見ていて思いましたので書かせてもらいました。
コモンセンス
会議室デビュー日: 2005/01/05
投稿数: 15
投稿日時: 2005-01-06 09:46
コモンセンスです。

objectさんの書き込み (2005-01-05 18:46) より:

>どの様な根拠で
>「メソッド」が「実装概念」になる
>のでしょうか？
(オブジェクト指向)プログラミングの世界以外では
出てこない(必要でない)概念だからです。

>そしてまた、どの様な理由で
>「論理概念として一級の座位を与えることはできない」
>という事になるのでしょうか？
自然言語のなかに自然な対応概念がありませんから。
(論理2000年の歴史のなかでも基本概念として扱われた
ことはないでしょう。OOPは高々20年です)

菊池さんの書き込み (2005-01-05 22:49) より:
>　しかし、何が論理概念で何が実装概念であるかなんて議論は閾値
>とする抽象度の設定次第でいくらでも結論が変わる事です。
>　どっちも論理概念であり実装概念だと思いますよ。

論理概念であるか実装概念であるかを問うているということは
もちろん同時にその判別基準を問うていることでもありますから、
ご指摘いただいたことではいまだ問いは解消されません。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2005-01-06 12:59
objectです。

>菊池さん
>データの存在が必要という論理概念は呼びの方向は意識しない事もできる。
上の「データ」は「情報、振舞」の「情報」を指すと思いますが、
オブジェクト指向の説明の中で
「情報、振舞」
というセットが、とても簡単(安易)に導入されています。
しかし、この「情報、振舞」という「カテゴリ」は極めて本質的で、
もし、これに近い概念を取り上げるなら、それは
「集合、写像」の概念(代数系)
だと思います。
#しかし、「代数系」を学んでみても、何故「集合、写像」という「カテゴリ」を導入するかは理解出来ないでしょう。
#「集合、写像」は、それ位に基本的な「概念セット」です。
#安易に、常識レベルでは判断しない方が良いと私は思います。

>取り出すというメソッド呼び出し
>or
>アクティブオブジェクトとかから呼びが出てきて渡される
これは、「ソフトウエア空間」での所謂「ゲッター、セッター」を考えていると思いますが、
上に書いた様に、実は
「情報、振舞」＝「集合、写像」
であり、極めて抽象化された概念であるという事を忘れてはいけないと思います。

--------------------------------
>コモンセンスさん
>(オブジェクト指向)プログラミングの世界以外では
>出てこない(必要でない)概念だからです。
先ず確認します。

コモンセンスさんは
オブジェクト指向 ＝ プログラミングの世界
と考えられてる訳ですね？
#ここは、私と基本的に異なります。

それから、オブジェクト指向での「情報、振舞」に於いて、
「メソッド」が「振舞」に相当しますよね？

この「振舞」に相当するものが、「プログラミングの世界」以外には存在しないと仰ってるんでしょうか？
#菊池さんへのレスで書きましたが、「振舞」＝「写像」です。

それから、
「メソッド」は、非常に「抽象化」された概念です。
「抽象化」されているという意味は、
そのままでは
「具体的なもの」に、「直接的」には対応していない　−(1)
という事です。

(1)を以って、
出てこない(必要でない)概念
とは考えていないでしょうか？

>自然言語のなかに自然な対応概念がありませんから。
>(論理2000年の歴史のなかでも基本概念として扱われた
>ことはないでしょう。OOPは高々20年です)
菊池さんへの説明でも書きましたが、「メソッド」概念を私なりに少し補足すると、
「メソッド」＝ 「写像(数学での)」
と言っても良いと思います。
この写像をベースに考えても、
自然言語のなかに自然な対応概念
を考える事は出来ませんか？
guion
常連さん
会議室デビュー日: 2004/12/24
投稿数: 30
投稿日時: 2005-01-06 13:17
objectさんの書き込み (2005-01-01 14:02) より:

>>ちなみにプロパティかメソッドかという違いは、文法上の些事でしかない、ともいえます。
>しかし、「オブジェクト指向」で言われる
>「情報・振舞」
>という「カテゴリ」は、
>普通にソフトウエア技術者が考えている以上に本質的で重要な概念

まあそれはいいんですが、
その本質な概念と、
ここで話題になってる言語仕様(C#とか)の内輪用語としての「プロパティ」や「メソッド」とが
どういう関係にあるのか？ってのが、まず問題かと。

言語仕様の中で使われてる用語は、
外界の定義(もし有るならば)との互換性が取れてる保証が無いのでは？

で、おのおのの言語仕様を合算して「なんとなく(厳密ではないので)」得られる、
「プロパティ」「メソッド」と呼べそうなもの、について、
上記の話(区別は文法上の些事でしかない)が言えてるようです、
というのが私の話です。

特にプロパティあたりは、コンセンサス有るんでしょうか？

>「プロパティ・メソッド」と「フィールド・ファンクション(含プロシジャー) 」を同じレベルで考える

ええと。「メソッド」という単語は、
どこでどう定義されたものを使って
今話してらっしゃいますか？

＃私が日頃関わってる言語だと、こういう場合は
＃「メソッドvsファンクション」じゃなく「メッセージvsメソッド」と呼称します。


>私は、今の「ソフトウエア科学」はある種の「ドグマ」に陥っていると思っています。
>そして、そのドグマを克服しない限り、
>「モデリング言語」はスタート地点に先ず立つ事が出来ない

「ドグマ」という言葉の意味はよく知りませんが、
「決め付けを充分に少なくしておかないと、モデリング言語として役立たずとなる」
であろうとは思います。

>私は、
>「プロパティ・メソッド」
>と
>「フィールド・ファンクション」
>を同じレベルで考えるべきでは無いし、
>「これらの関係を整理し直す事」
>が重要だと思っています。

それは、名前空間次第だと思います。
どこで定義された語なのか？という問題。

なんとなく(^^;プロパティと呼ばれてるものを見回すと、
確かにそれは「フィールドとかより高級なもの」を指している
ようだとは、見て取れます。

が、レベル(って何？)が違うとまで言い切れるかどうかは、
名前を定義してる場次第でしょうね。
＃objectさんの中の定義空間では、言い切れるのは確かなのだとは思います。

>これらの概念を支える視点を強いてあげれば、
>「プロパティ・メソッド」->「モデリング言語」
>「フィールド・ファンクション」->「プログラミング言語」
>と言えると思います。

そういうくくり方は、 (このThreadの文脈つまり名前空間では)
不味いんじゃないでしょうか？

ここの文脈だと「プロパティ」は
UMLとかなんとかから出てきたわけではない、
特定のプログラミング言語(C#)での用語、でしょうから。
というか、C#のプロパティは、元を正せば、
これまたプログラミング言語であるDelphiの真似でしょうから、
ますますモデリング言語との縁は薄そうです。

一方、モデリング言語だということになってる(^^;UMLには
プロパティが無いわけで…
なんというか、「逆転現象」が生じていますね。

で、私としてはこの逆転は「興味深い(というか傍で笑って見てる感じ)」んですが、
objectさんとしては、もしかして「認めたくない」という感じ、だったりするんでしょうか？

ちなみに私が笑っていられるのは、
名前空間が別だ(と少なくとも私は見なしてる)からです。
統一を焦ってないから。

まあ統一されたほうが楽だろうとは思うんですが、
OOの方法論なり言語なりを見るにつけ、
「制定者の数だけ、概念(とその名称)の定義が有る」
という状況は何十年も変わってないようなんで、
OO畑については、ヘタに統一すると、
自由度を単純に縛るだけになっちゃうんじゃないか
という心配のほうが大きいです。
＃それこそUMLが結構多くの人々の「思考を規定」しつつあるように。

現実的に言えば、OOって、結構アヤフヤな概念だと思います。
もちろん譲れない線は有るんですが、困ったことに、
その線の位置は、人によって結構微妙に違ったりしてて、
しかもそれぞれにそれなりに一理有る。(よほどのヘボな人は除きますが)
«前のページへ 1|2|3|4|5 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）