- - PR -
記事:メソッドとコンストラクタはなぜ必要? はおかしくない?
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-05-13 17:14
「メソッドはなぜ必要か?」という問いに対する答えは
「隠蔽されたフィールドにアクセするため」が正解 なのではないのでしょうか? 記事の説明だと、繰り返される「処理」に着目していて、 これは構造化手法の話に聞こえます。 それはそれで必要だとは思いますが、オブジェクト指向言語としての 観点からの説明が無いのは納得がいかない感じがしました。 それとも今後に書く予定でしょうか? # 今回から執筆者は替わったようだけど、 # この連載の内容は毎回不満が残る | ||||
|
投稿日時: 2003-05-13 20:52
確かに何か納得できない解説ですね。
この記事の場合完全に実装(コーディング)の話だけですし。 本来はもっと概念的な話があって、ではそれを実現するには メソッドを使います、と言う流れかと思います。 「隠蔽されたフィールドにアクセするため」も少し違うのでは？ それはアクセサだけの話ですよね。当然フィールドにアクセスしないメソッドもある訳で。 なぜ必要か？と言うアプローチ自体に違和感を感じますが、 僕の考えとしては 「そのオブジェクトが外部に対して公開(提供)する機能」 なのかなと思いますね。 | ||||
|
投稿日時: 2003-05-13 21:01
オブジェクト指向は構造化手法（カプセル化）の延長上にあるかもしれませんが、
インスタンスを生成するための手順としてのコンストラクターとか インスタンス化したオブジェクトへ処理を渡す手段としてのメソッドとか mainメソッドはかなり特殊な物でほとんどのクラスに実装されないとか そういった基本的な説明の無いままにJavaのステートメントの説明を進めているのが 納得いかないのだと思います。 この連載の対象読者がプログラムをしたことが無い人もしくはそれに近い人のようです。 そういった素人にJavaの書き方を伝える為にある意味ウソを教えているように感じます。 アルゴリズムを伝えるためのプログラム言語はpascalが最適だと思いますが、 今の人たちはいきなりJavaから入ろうとするために変な記事になってるようですね。 非常に残念です。 | ||||
|
投稿日時: 2003-05-13 21:20
>「隠蔽されたフィールドにアクセするため」も少し違うのでは？
>それはアクセサだけの話ですよね。 私の意図は、 「クラスが持つデータを隠蔽するためにはメソッドが必要」つまり 「隠蔽されたデータにアクセスするためにはメソッドが必要」 ということです。ゲッタやセッタのみではなく。 「なぜ」に対する答えはもちろん複数あるとは思いますが、 これが主目的ではないかという意味です。 >当然フィールドにアクセスしないメソッドもある訳で。 あるとは思いますが、主な目的ではないでしょう。 | ||||
|
投稿日時: 2003-05-14 06:42
茶葉さん：
> 「クラスが持つデータを隠蔽するためにはメソッドが必要」つまり > 「隠蔽されたデータにアクセスするためにはメソッドが必要」 そもそも、隠蔽されてるデータなんてものを意識させる必要はないのではないですか？ 何かのメソッド（メッセージを受けた後の振る舞い）を、どんなデータを用いて どう実装してるかには使用する側は興味がないと思うんですけどね。 当然のことながら多くのメソッドは中のデータにアクセスはしてるでしょうが、 メソッドを呼ぶ場合の主となる目的は機能の実現かと。 そういう意味で、 YOU@ITさん： > 「そのオブジェクトが外部に対して公開(提供)する機能」 ってほうがピンと来ます。 | ||||
|
投稿日時: 2003-05-14 11:26
privateメソッドを忘れていませんか？
「（インスタンス化したオブジェクトへ）処理を渡す手段としてのメソッド」 がもっとも広範囲な意味でのメソッドの意味だと思います。 また、「（公開されている）属性へのアクセス方法を一般化するためのメソッド」 というのもありますよね。 | ||||
|
投稿日時: 2003-05-14 11:34
ども、ほむらです。
この連載に関しては最初JAVAなのにハードに着目して 説明してしまった時点で失敗だったのではと、思っています。 あくまで、個人的偏見なのですがJAVAはソフトのことだけを考えれば 良くて、メモリ空間とか領域なんて知る必要は無いという感じです。 なんとなく、一生懸命に軌道修正をしようとしているような 感じが見え隠れしている気もするので、 これからの成り行きに期待をもってしまいます。 ----------
僕もそう思います。 メソッドはあくまでクラスに対する操作と クラスとして実現する機能提供だと思っています。 メソッドの内部で都合として隠蔽されたデータにアクセスすることはあっても 隠蔽されたデータにアクセスするためのメソッドという表現では隠蔽することが ただ面倒に感じてしまうだけのように思います。 たとえば、データ件数を取得するなんていうメソッドがあった場合 データ件数を取得するという機能はかわりませんが メソッド内部で、インスタンス変数を直接返しているのか 有効なデータを検索して返してきたいるのか使う側はしらなくても良いことです。 通常のJAVAには無いみたいですが、茶葉さんの表現があたるのは メソッドでなくて、プロパティにあたるのではないでしょうか？ プロパティ？を説明するのなら '隠蔽されたデータにアクセスするためのメソッド'という表現も ありだと思います。 | ||||
|
投稿日時: 2003-05-14 12:09
私には全然そうは見えないです。 何が原因かといえば要はこの記事の著者が構造化プログラミングの パラダイムから抜け出していないだけでしょう。 それでも一応それなりに動くものは作れてしまうので、理解した気に なっているだけなんじゃないでしょうか。 で、第5回の記事の中でもその臭いはプンプンしていて、あまり軌道 修正がかかっているようには見えません。 「Mainメソッドがすっきりした」などという文言からも明らかでしょう。 それとも対象読者をCOBOLなどしかやっておらず、オブジェクト指向の 素地がない人々と想定してわざと確信犯的にやっているんでしょうか。 だとしてもやっぱりお粗末ではあります。 JavaだのC++だのといったいわゆる「オブジェクト指向プログラミング 言語」というヤツは、その背景にある「オブジェクト指向」という 考え方でシステムを実現するための実装にしか過ぎません。 その実装だけを捉えて「こう動くからこうなんだ」といった理解を するのは、HTMLでブラウザに表示される文字を大きくしたいためだけに h要素を使うのと同じく間違っています。 この連載を読んでJavaがわかった気になった人がいるとしたら その人にとっては不幸なことです。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。