- - PR -
getter/setter
1|2|3|4|5
次のページへ»
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-16 14:56
はじめまして。自己流でjavaの勉強をしています。
初投稿です。よろしくおねがいします。 オブジェクト指向プログラミングについての解説で、 フィールドのカプセル化とgetter/setterの説明をよく見かけます。 フィールドはprivate属性にし、他のクラスから参照/更新をする際は、 public属性のgetter/setterメソッドを介してのみ行う、という説明の意味自体は、 自分なりに理解しているつもりです。 ところで、それを知って以降、コーディングのたびに疑問に思うことがあるのですが、 ******************************************************************************* フィールドの参照/更新を、他クラスからではなく、自クラス内で行う場合にも、 やはりgetter/setterを使った方がいいんでしょうか? それとも、自クラスのフィールドの場合は、 直接、フィールドの参照/更新をしてしまっていいんですか? ******************************************************************************* 皆さんはどういう理由でどうしているか、教えてください。 | ||||||||||||||||
|
投稿日時: 2004-09-16 15:41
もしこれがダメだと言うのであれば以下のコードもダメということになります。
ちょっと天の邪鬼のような発言ですが、自クラスのメンバ変数を直接操作してはいけないならゲッター・セッターもやってはいけないはず。 なので私は普通に直接操作をしています。 自クラス内でゲッター・セッターを多用するとコード自体がスパゲティ化するので見づらくなるというのもあります。 | ||||||||||||||||
|
投稿日時: 2004-09-16 15:53
こんにちは。 カプセル化は「外」に対しての防御です。 外部に対してブラックボックス的に使えるようにそういう仕組みにしてるんです。 内部では基本はprivateを直更新します。 作った人がその変数を間違えて使ったりしたら、それは論外です。 正しくプログラムが書けるようになるしかないです。 あくまで、基本です。例外もあるでしょう。 もう一度オブジェクト指向の考え方を考えてみてください。 コーディングスタイルではなく。「概念」が大事です。 _________________ | ||||||||||||||||
|
投稿日時: 2004-09-16 15:53
ちょっと追加を。
publicなsetterメソッドが、もしsynchronizedだったら、 自クラス内でも、setterメソッドを使用するべきでしょうね。 それ以外の場合は・・・、私は、setterを使う派かな。 うまくいえませんが、コードの記述を抽象化する効果がありますし。 確かに冗長にはなりますが、スパゲティ化するとは思わないです。 | ||||||||||||||||
|
投稿日時: 2004-09-16 17:40
setter/getter を使うメリット。
単なる代入・参照と異なり、代入検査・加工などを行うことができる。 将来、代入検査が追加される可能性などを考えるなら、自クラス内でも setter/getter を使うべき。 | ||||||||||||||||
|
投稿日時: 2004-09-16 17:57
「自己カプセル化」と言う手法もあり、自身のフィールドに対しても アクセサを使用することはあります。 あとは命名と言うところもありますね。 例えばMap型のフィールドを持つクラスに、何らかの情報を登録する場合は、
ではなく、
のようにした方が、直接"put"するよりも"registerValue"のような 名前を付けた方がわかりやすいと思います。 あと、上記のようなCollectionに値をセット・取得する場合は キャストする手間が省けたりというメリットもあるかと思います。 とは言うものの、いつも自己カプセル化するか?というとそうではないです。 結局はケースバイケースですね。 | ||||||||||||||||
|
投稿日時: 2004-09-16 18:23
どもです。がるです。
setter&getterのお話、懐かしいです〜。 個人的には「クラス内でもメソッドでアクセス」に一票。 そのほうが「より安全かつ柔軟に」コーディングが可能に なります。 例として。 セッターの便利なところの一つに「入ってくる値のチェック をしてから変数を設定することが可能」ってのがあります。 この辺の機能をあちこちに散らかすよりは、setter一本に ぶち込んでしまったほうが後々楽ができます。 getterは微妙なのですが。もし万が一、クラスの修正などで 「変数がなくなって、別の(複数の)変数からの演算結果で」 そのデータが算出される事になってしまった、なんてときに、 getterにしておくと楽です。 いくつか軽く反論(ってほど大げさでもないのですが)を 書いておくと。 ゆっきさんの
は「setter/getter以外のメソッドでは変数を直接操作しない」という 言い方で置き換えれば問題ないか、と思います。
基本的に、ソースがスパゲティ化するのは「設計やクラスの 切り分けなど」が要因なので、今回の件とはあまり関連性が ないように思うのですがどうでしょうか? 「プログラムの文章量が若干増える」という意味ではYesだと 思うのですが。 CHNさんの
は、悩ましい問題ですね。 ただ、私は「昨日の自分は赤の他人」だと思っているので :-P
これは多分、基本的に非常に正しいとは思うのですが。 ただ実際のところ「それでもミスをしてしまう」人ってのは 絶えないと思うわけでして。 そのあたりのケアレスミスやら修正ミスやらってのを「方法論で 可能な限り防ぐため」って考えると、内部でもsetterとか使った 方が「より安全かなぁ」とか思っちゃうんですね、私は。 んでまぁ実際は「面倒でつい変数を直接」ってのも多々あるのですが :-P 可能な限り、ちゃんと意識してsetterとか使うようにしてます。 [余談] 「まぁこれくらいいいや」って手を抜いてるところに限って、 後で変更がはいって泣きを見るものです(笑 [/余談] | ||||||||||||||||
|
投稿日時: 2004-09-16 19:06
わっきー@初書き込みです。
なかなか面白い議論ですねぇ。 で、私も思うところがあるので一言。
この状態っていうのは「プロパティのカプセル化のためのアクセサ メソッド」が、そうでなくなってしまった訳ですよね。 たとえば class 商品{ get希望小売価格(); // (A) get消費税額(); // (B) } があったときに、(A)はプロパティのアクセサメソッドですが、(B)は 必ずしもそうであるとは限らないと思うわけです(DB設計で言うところの 導出項目になりえる)。 で、がるがるさんの書き込みの内容だと「(A)のタイプのメソッドが (B)のタイプのメソッドに化ける」ということ? このような状況だと、「分析結果を実装する」時点の問題では無く、「分析結果 そのもの」に問題があるように思います。 (たとえばこのようなケースの場合、setterメソッドそのものの要/不要の 判断が必要となってくるような、、、) 言いたいことは何かというと、ここでがるがるさんのおっしゃるgetterは プロパティアクセサとしてのgetterでは無く、純粋なロジックとしての getterであると思うのですが、、、どうでしょう? 以上、あげ足とるような書き込みで申し訳ありませんでした。 |
1|2|3|4|5
次のページへ»