[jfriends] Re: [jfriends] Re: staticの使い方（メソッド）

[Kazuya Maebashi <maebashi@xxxxxxxxxx>]

前橋＠OOP劣等生? です。

遠藤さん:
>新しい概念を知ろうとするとき、はじめは既存の知識から類推し
>たりするわけですが、その新しい部分というのは、今までのコン
>テキスト(文脈?)の延長からはどうやっても導出できないというこ
>とがあり得ます。
<後略>

そう思います。

私も、「COBOLプログラマのための、C言語入門」みたいな本は、
大嫌いだったりします。

で、私は、手続き指向言語(Cとか)の鎖から、全然解放されてない
でしょうか...(どきどき)

たとえば、先のオセロのクラス構造は、OOPをバリバリに適用して
設計すれば、どんな形になるのでしょうか?

自分なりに、OOPしてみたつもりだったのですが...

できれば、遠藤さん・水野さんのご意見をいただきたいです。

ところで、

>「Javaのインスタンスはポインタに過ぎない」
>「メソッドは関数ではないのか」

表現の問題だけかも知れませんが、これについてはちょっと言いた
いです。

私の主張は、

「Javaのインスタンスはポインタに過ぎない」

ではなく、

「Javaで参照と呼んでいるものは、ポインタである」

です。

インスタンスはポインタではありません。ポインタに指される先に
ある、何らかの実体です(よね?)。

# それとも、「インスタンス」という用語の解釈が間違ってますで
# しょうか?

最近の話題からすると、

(オセロのJudgeの説明)
>>・Boardと、ふたつのPlayerに対してポインタを保持します。
>「Boardのインスタンスと、ふたつのPlayerインスタンスを保持します」
>の方が分かりやすいです。

Judgeが、Boardの実体や、ふたりのPlayerを、自分のふところに抱
え込んでいる、という見方は、(不自然ながら)まあできるかもしれ
ませんけど...

(Playerの説明)
>>・Boardに対してポインタを持ちます。
>「Boardのインスタンスを保持します」かな。

Playerが、それぞれにBoardを抱え込んでいたりしていたら、ゲー
ムになりませんってば。(^^;

# そういえば、「潜水艦ゲーム」とかいうのがあったかな。
# それぞれがBoardを隠し持ち、座標を言いあって、相手の船を撃
# 沈するやつ。

Judge, Player, Boardは、あくまで独立して存在し、Judgeは、
Boardと、ふたりのPlayerに対して、関係を持っています(実装レベ
ルでは、これがポインタ)。だから、Boardを見てゲームの終了を判
断したり、Playerに対して「次、君の番ね」と指示したりできるの
です。

同様に、Playerは、ひとつのBoardと関係を持っているので、手を
指すことができるのです。

>「インスタンス保持」というと、そのインスタンスを包含している
>(他の人は絶対にそれを指していない)ような気がしてしまうので、

ここ↑で書いたのは、そういうことです。

だから、例えば、「人間」クラスのインスタンスである「前橋」オ
ブジェクトが、「脳味噌」のインスタンスを保持している、という
のなら、事実だと思いますけど。
# nullだったりして(^^;

ポインタという概念(と用語)は、オブジェクト指向と、相互に背反
するものでしょうか? 私はそんなわけないと思っています。それど
ころか、ポインタにより、オブジェクトの相互の関係が構築できる
のですから、オブジェクト指向にポインタは必須でしょう。

# そういえば、OMTとかUMLでは、関係を矢印ではなくて線で示しますね。
# これは、双方向のポインタになるわけですが、片方向のポインタで
# 済む場合も、それを表現する記法が、確か無かったはず... デザイ
# ンパターン本では、矢印で表現してましたけど、でも、実際の設計
# では、片方向のポインタで済むつもりでも、たいていそのうち両方
# 向持ちたくなるんだよなあ...

むしろ、Javaの本では、何故どいつもこいつも「Javaにはポインタ
がない」と主張しているのかの方が謎です。

Javaのポインタには、ポインタ演算はありませんけど、それは、
C や C++ のポインタの方が特殊なのです。

また、

「メソッドは関数ではないのか」

ではなく、

「インスタンスと結び付かない、『関数』と呼ぶべきモノは、
  存在するのではないか」

です(しばらくやりとりしていて、ようやく自分でも分かってきた
気がします)。

私の理解において、(今のコンテキストにおける)関数と、メソッド
は別物です。メソッドは、インスタンスに結び付いています。それ
に対し、インスタンスとは結び付かない、独立した関数、ってもの
があるだろう、ということです。

sin()やcos()のような算術関数や、給与計算の式などがそうじゃな
いか、ということですね。

# 関数が、クラスの中に存在していたからといって、それがstatic
# であれば、名前空間の問題だけで、独立した関数と結局一緒ですね。

私は、「社員」オブジェクトの気持になることはできます(という
か、社員そのものだってば)。オセロのPlayerやJudgeやBoardの気
持ちになることもできるでしょう。

でも、給与計算のための、「社内規則」の気持ちにはなれません。

そこには、「規則」はあれど、オブジェクトがないからでしょう。

「俺が規則だ! てめえらの給料は俺が決めちゃる」というワンマン
社長のいる会社なら、給料決めるオブジェクトが実在している気が
しますが、(^^; 幸いにしてうちの会社はそうではなくて、算出規
則が存在します。

その規則に、勤続年数と、等級を放り込むと、基本給を返してくれ
たりするわけです。これは、(うちの会社だけを扱う限りにおいて
は)ひとつしかない、唯一絶対の規則です(だと思う)。

それに対して、オブジェクトは何らかの状態を持ちます。

オブジェクトに対して、基本給の問い合わせを行なうのは、ワンマ
ン社長に給料を聞いている時のように、

・毎回違う額を返されたり、
・給料を聞くことによって、知らないところで何か副作用が発生してたり

しそうで、なんかヤダ、と、私は感じるわけです。

数学における公式とか、物理法則とかいうのも、唯一絶対、ひとつ
しかない規則で、何ら副作用を持たないですよね(とゆーか、規則
に作用があるわけがない)。この手のものが、何らかのインスタン
スと結びつき、インスタンスのメンバを参照できる、となると、ど
うしても違和感を感じてしまいます。

だから、Mathクラスのメソッドは、staticになっているのだと思い
ます。

こういうのを、「例外中の例外」と片付けてしまって良いものでしょうか?

他にも、きっとあると思うのですが。

あ、もちろん、もし、給与計算規則が、唯一絶対の規則ではなく、
たとえば、複数の会社を扱わなければならないのなら、それぞれの
規則ごとにクラスを作成し、そいつらが「給与計算インタフェース」
を実装する、という形になるんでしょうね。

>確かにこのような側面もあるでしょう。
>でも Java の良さはこういうところには無いのです。
>
>たとえば、
>
>最適な粒度のオブジェクトを組み合わせることで、最大限の効果
>が得られるのです。
>
>オブジェクトは、その担うべき責務をはっきりさせることでプロ
>グラマーの頭を整理し、プログラマーの負荷を減らします。

これはそうだと思います。

>Javaに限らず、オブジェクト指向の世界では、オブジェクトの気
>持ちにならなければ見えてこない面があるのではないかと思っています。
>それは既存のポインタ、関数という切り口からは切り取れない、
>いわく言いがたい側面かもしれません。

個人的には、

オブジェクト(データ+メソッド)でうまく表現できる所は確かにある、
でも、(Mathクラスのように)そうでない所もある。

クラスが作れるのはいいんだけど、C++みたいに、クラスの外に、
手続きや変数も書ける方が、いいんじゃなかろうか? 名前空間は、
また別の方法で隠蔽するとして。
# でも、グローバル変数は、あんまり使いみちなさそうだけど。

その代わり、クラスには、staticなメンバは許すべきではない、
ような気がする。んだけれども、どうかなあ、うーん。
# あるクラスにしか見せたくないグローバル変数、とかは、何らか
# の形で名前空間を実現するとして。

と思っています。

>このような「オブジェクト指向の発想法」について書かれた有名な本として、
>この本を紹介しておきます。
...
>http://www.sra.co.jp/people/aoki/IntroductionToOOAOOD/index.htm
>
>＃ 名古屋でこの本の読書会やりませんか？>前橋さん^^;

紹介ありがとうございます。

って、それはいいんですが、絶版の本で、どうやって読書会を...
と思ってWebページを見たら、全文公開ですか。

読書会はともかくとして、ぼちぼち読んでみます。

# 本の形になってないと、不便ではありますけれど。持ち歩けない
# もんなあ。読み終わるのはいつになることか。

ところで、連休明けまで出てこないんじゃなかったのかって?

メイルばかり書いてて、仕事しなかったので、今日も出てくるハメ
になってしまったのです(^^;

で、今日もまた、こんなに書いてちゃ...

でも、明日からは休みます。断固として。

------------------------------------------------------------
  前橋 和弥                             maebashi@xxxxxxxxxx
  中部ソフトエンジニアリング(株)
    〒450 名古屋市中村区名駅4-10-25(名駅IMAIビル 5F)
    Tel:(052)583-4511(代) 内線 252 Fax:(052)583-4566
------------------------------------------------------------