[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jfriends] Re: [jfriends] Re: staticの使い方（メソッド）
>前橋＠OOP劣等生? です。
私もオブジェクト指向が分かっているわけではないです。
(何でもそうですが、分かったと思ったらそこで終わりかも知れません)
>で、私は、手続き指向言語(Cとか)の鎖から、全然解放されてない
>でしょうか...(どきどき)
あまりカタくならないほうが良い、ということは言えます。
初めての言語が Java だった人は、「クラスって何？」とか
考えなくてもプログラミングしているようですし。
オブジェクトに身を委ねるのです。:->
>たとえば、先のオセロのクラス構造は、OOPをバリバリに適用して
>設計すれば、どんな形になるのでしょうか?
>
>自分なりに、OOPしてみたつもりだったのですが...
人それぞれ好みがあるので、意見はいろいろ出ると思います。
でも前橋さんの設計が「オブジェクト指向的でない」とかいうわけでは
ないと思います。
「正しいオブジェクト指向」とかいうものがあるわけではないでしょうから。
>インスタンスはポインタではありません。ポインタに指される先に
>ある、何らかの実体です(よね?)。
>
># それとも、「インスタンス」という用語の解釈が間違ってますで
># しょうか?
うーん。
「インスタンス変数」が保持しているのは「インスタンスの参照」なのですが、
「インスタンスそのものを保持している」と考えても特に支障が無いのでは？
>Playerが、それぞれにBoardを抱え込んでいたりしていたら、ゲー
>ムになりませんってば。(^^;
この場合は Board がひとつしかない、ということを意識しなければならない
わけですね。
>>「インスタンス保持」というと、そのインスタンスを包含している
>>(他の人は絶対にそれを指していない)ような気がしてしまうので、
>
>ここ↑で書いたのは、そういうことです。
私は「保持」に「内包」までは含めて考えないというか、
そこまで厳密に考えていなかったようです。
>ポインタという概念(と用語)は、オブジェクト指向と、相互に背反
>するものでしょうか? 私はそんなわけないと思っています。それど
>ころか、ポインタにより、オブジェクトの相互の関係が構築できる
>のですから、オブジェクト指向にポインタは必須でしょう。
SmallTalk はやったことがないのですが、
すべてがオブジェクト(値もオブジェクト) だったとすると、
「指し示している(場所の)値」(指し示している実体じゃなくて)というものに
意味があるんでしょうか。
># そういえば、OMTとかUMLでは、関係を矢印ではなくて線で示しますね。
># これは、双方向のポインタになるわけですが、片方向のポインタで
># 済む場合も、それを表現する記法が、確か無かったはず... デザイ
># ンパターン本では、矢印で表現してましたけど、
表記法が実装を制約しているわけではないので、私はあいまいに考えていました。
>でも、実際の設計
># では、片方向のポインタで済むつもりでも、たいていそのうち両方
># 向持ちたくなるんだよなあ...
実際にはお互いに相手を知っているほうが便利なケースが多いですね。
片方で済む場合は片方で済ませたほうが良い設計なんでしょうが。
>Javaのポインタには、ポインタ演算はありませんけど、それは、
>C や C++ のポインタの方が特殊なのです。
そうですか？
私はCとPascalしか知りませんが、
「型を持ったアドレス値」以外の形でポインターを実現している言語は
あるのでしょうか。
>「インスタンスと結び付かない、『関数』と呼ぶべきモノは、
> 存在するのではないか」
クラスを離れたメソッドは存在しないので C の関数みたいなものは存在し得ないですが、
クラスメソッドというものは存在してます。
クラスを離れたメソッドは存在しないので、
C の関数ポインターみたいなものは存在し得ないですが、
interface というものは存在してます。
給与計算と sin()、cos() についてですが、
給与計算はある特定の(Coadの用語の)問題領域のメソッドで、
sin() cos() は一般的な数学計算のメソッドですよね。
ここで Math のような汎用のユーティリティークラスの計算メソッドと、
「給与計算規則」のような特定の問題領域クラスのメソッドを
一緒に論じないほうが良いのではないかと思います。
>あ、もちろん、もし、給与計算規則が、唯一絶対の規則ではなく、
>たとえば、複数の会社を扱わなければならないのなら、それぞれの
>規則ごとにクラスを作成し、そいつらが「給与計算インタフェース」
>を実装する、という形になるんでしょうね。
唯一絶対の規則でないことの方が多いです。
数学の公式のように誰でも共通に使うものは数としては少ないと思います。
>クラスが作れるのはいいんだけど、C++みたいに、クラスの外に、
>手続きや変数も書ける方が、いいんじゃなかろうか? 名前空間は、
>また別の方法で隠蔽するとして。
それは C++ で書けば良いのでは？
Java は C++ とは「別の山を登る」ことにしただけです。
私はクラスを離れたメソッドが無いというのは長所だと思っています。
>その代わり、クラスには、staticなメンバは許すべきではない、
>ような気がする。んだけれども、どうかなあ、うーん。
私はクラスメソッドが無くても良かったかも知れません。
でもあっても良いです。
(C と同じ static という予約語を使ったのは失敗だったかも知れません)
># あるクラスにしか見せたくないグローバル変数、とかは、何らか
># の形で名前空間を実現するとして。
>
>と思っています。
名前空間については知らないのでなんとも言えません。
(仕事で使うときには覚えよう..)
># 本の形になってないと、不便ではありますけれど。持ち歩けない
># もんなあ。読み終わるのはいつになることか。
私の場合は会社で印刷して章ごとにホチキスで閉じて電車の中で
読むというパターンです。(Java 3D API Specificationはそうやって読んだ)
この本はときどき大きい書店に残っていることがあるので、
探すと見つかるかも知れません。
同じ著者によるこの本の続編はまだ絶版になっていません。
http://www.src-j.com/BOOK_NO/032.htm
>タ イ ト ル ： 例題による!!
> オブジェクト指向分析設計テクニック
>著 者 名 ： 青木 淳
>装 丁 ： Ａ５判・ハードカバー・２８４頁
>価 格 ： 定価[本体￥４，６６１＋税]
>初版発刊日 ： １９９４年３月１日
>Ｉ Ｓ Ｂ Ｎ ： ４−９１５７７８−３２−０
>【目次】
>
>第１章 基本クラスライブラリの開発
>
> 1.1 オブジェクト指向の分析設計作成に際して
> 1.2 オブジェクト指向のプログラム制御構造とメモリ管理
> 1.2.1 関数閉包と遅延評価
> 1.2.2 メッセージの送信形態
> 1.2.3 オブジェクトの生死
> 1.3 クラスライブラリはツリーではない
> 1.4 集まりを表すオブジェクトの分析設計作成
> 1.4.1 問 題
> 1.4.2 問題領域の分節化
> 1.4.3 オブジェクトモデル
> 1.4.4 操作メッセージの考察
> 1.4.5 考察と評価
> 1.5 幾何学図形オブジェクトの分析と設計
> 1.6 認知的経済性と共有可能性
>
>第２章 グラフィカルユーザインタフェースの分析設計
>
> 2.1 なぜ形式化が必要か
> 2.2 グラフィカルユーザインタフェース
> 2.3 モデルビューコントローラ
> 2.4 ゲージを作ろう
> 2.4.1 形式の利用
> 2.4.2 形式への布置
> 2.4.3 作成する環境を考える
> 2.4.4 オブジェクトモデルを見直す
> 2.4.5 機能を考える
> 2.4.6 事態を考える
> 2.4.7 プログラムを書く
> 2.4.8 テストし性能を評価する
> 2.4.9 インテグレーションする
> 2.5 もう一つのゲージを作ろう
> 2.6 グラファの考察
> 2.7 オブジェクト指向のやり方
>
>第３章 オブジェクトモデルのメタモデル
>
> 3.1 最近のスタイル
> 3.2 正常と異常
> 3.3 構造と機能
> 3.4 オブジェクトはどこにいるのか
> 3.5 モデルとは何だろう
> 3.6 メタモデルとは何だろう
> 3.7 オブジェクトモデルのメタモデル
> 3.8 モデルとシュミレーション
>
>第４章 ビジネス系アプリケーション
>
> 4.1 殻(encapsulator)と場(field)
> 4.2 格納庫(storage)
> 4.3 著作物管理問題
>
>第５章 コントロール系アプリケーション
>
> 5.1 約束(promise)と将来(future)
> 5.2 リフト制御問題
> 5.3 信号機制御問題
言語は SmallTalk です。
--
えんどう やすゆき <yasuyuki@xxxxxxxxxx>
http://www.javaopen.org/jfriends/ (Java互助会ホームページ)