- PR -

JAVAにおけるstaticメソッド

1|2|3|4|5|6|7 次のページへ»
投稿者投稿内容
北斗のポン
会議室デビュー日: 2003/05/02
投稿数: 17
投稿日時: 2003-05-02 16:35
いや〜、書き込み始めるととまらないですねぇｗ
ついでなので、前から気になることで皆さんからの意見を聞きたいと思います。

「オブジェクト指向言語」である「JAVA言語」ですがstaticについての意見が分かれているようですね。
んで、私的にはユーティリティー的なクラス（例えば入力チェックなどはこのクラスに任せてしまう）を作ってそこにstaticなメソッドをたくさん作り色々な場所で使いまわすのがすきなのですが、ある人に
「Javaはオブジェクト指向の言語だからstaticなメソッドは極力作らないほうがよい」
と指摘を受け、仕方無しにソースを直したことがあります。
でも、実際にはJ2SEのAPIの中でもIntegerクラスのparse()やSystemクラスのexit()などのようにインスタンスの中で値を保持しないようなものはstaticなメソッドとして定義されています。
皆さんはどのようにしているのでしょうか？

あまり有意義なスレッドでない上に、結論からしては「好きにすればいいんじゃないの」となってしまうかもしれませんが、皆さんの意見を聞ければ幸いです。
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2003-05-02 16:54
参考にされているAPIをよく理解していないようですね。
staticであるものはきちんと理由があります。

自作のユーティリティクラスはモデリングされてましたか？
どのような用途のものも一つのクラスに詰め込んでいるようなデザインだから
オブジェクト指向うんぬんという指摘を受けたのだと想像できます。

インスタンス化のコストを考えるとなんでもかんでもオブジェクトにするのも
間違っています。

static節から直接呼ばれるメソッドはstaticである必要があったりするように
言語上の制約からstaticで実装しているものもたまにあります。

クラス変数とインスタンス変数とメソッド変数の挙動を学習してはいかがでしょうか？

ついでに、staticについて意見が分かれているという表現は勘違いだと思います。
staticをどう使うべきかというポリシーの議論と、
staticがどういう物かというのは別世界の話です。

で、オブジェクト指向であるかどうかにかかわらず、
意味も無くstaticを乱用するとモデリングが適切に行われなくなる危険性があるので、
乱用するなということです。
HALcat
会議室デビュー日: 2003/04/22
投稿数: 3
投稿日時: 2003-05-02 17:24
引用:

自作のユーティリティクラスはモデリングされてましたか？
どのような用途のものも一つのクラスに詰め込んでいるようなデザインだから
オブジェクト指向うんぬんという指摘を受けたのだと想像できます。


「雑用係」とか、「便利屋」とかいうモデルはありえませんか？
デザインって自由だから難しいですよね。
モデリングの決まった（一般的な）やり方ってあるんでしょうか？
ぼくも毎回、悩んでたりします。
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2003-05-02 17:45
「雑用係」とか、「便利屋」って面白い表現ですね。
いただきです。

どちらも可能な役割が決まっているはずです、
ですからimplementsしているインタフェースが大量にあったり、
Javaではできませんが多重継承が沢山あるということですよね。

ただ、気をつけないと、それを分解してモデリングした際に、
一人の開発者しか使わないクラスで
メソッドが１つしかない非常に粒度の細かいモデリングになりがちです。
（場合によってはそれもおｋですが。）

複数人で開発する場合はソースコードを共有して、
自分の利用するメソッドを追加していくような動きが必要だとは思います。

モデリングで悩むときは共同開発者（がいれば・・）に相談するのが一番です。
たとえ格下でも同じ開発者なのですから。

ちなみにモデリングで悩まない人って天才ですよね。
私も悩んでは失敗してます。そして失敗かどうかは後になってから判るんですよねぇ・・

おっと、本題が・・
モデリングの一般的なやり方＝デザインパターンとかブループリントですね。
SUNのJ2EEとかその辺に転がってると思うので参考になると思います。
ただし、物によっては実践的でないものもありますので
アマゾンで評価の高いものを選んではどうでしょうか。
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2003-05-02 18:12
和訳したものだとイマイチニュアンスが伝わらないことがあるから、
洋書を読みたいけど洋書を読むには時間がかかる今日この頃です・・

「俺流モデリングinJava」とか出版したら印税で食べていけるかな・・・
文才無いから無理か
北斗のポン
会議室デビュー日: 2003/05/02
投稿数: 17
投稿日時: 2003-05-02 18:14
早速の返答ありがとうございます。

以前に先輩から紹介された書籍を少し覗いたときに（書籍名は忘れてしまいましたが）、
「staticはインスタンス内に値を保持しない処理を行う時にはstaticメソッドもいい」
というようなことがかかれていたので、なるほどと思い今の考えにいたったわけでしたが・・・

これを言うと怒られてしまうかもしれませんが、モデリングという視点からは今まで考えたことがなかったですね。
というか、今までのプロジェクト自体が整ったものを経験したことがなかったもので、いつもプログラマーが独自に「便利屋」(私もいただき)を作っている人が多かったです。

まだ、JAVAをはじめて間もないのですが、早めに指摘をいただいてよかったです。
ありがとうございます。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2003-05-03 09:23
unibon です。こんにちわ。

引用:

北斗のポンさんの書き込み (2003-05-02 18:14) より:
以前に先輩から紹介された書籍を少し覗いたときに（書籍名は忘れてしまいましたが）、
「staticはインスタンス内に値を保持しない処理を行う時にはstaticメソッドもいい」
というようなことがかかれていたので、なるほどと思い今の考えにいたったわけでしたが・・・

書籍は知らないですが、私の推測では、これの具体例は、

コード:
import java.util.*;

class A {

    private int f;
    public int get() {
        return f;
    }
    public void set(int aF) {
        f = aF;
    }
    public Date getNow() {
        return new Date();
    }
    public int getSum(A a0, A a1) {
        return a0.get() + a1.get();
    }
}

のようなときに、上記の getNow メソッドや getSum メソッドを static にするかどうか、
ということかな、と思いました。
＃以下、この仮定で書きます。

コードを書いていると、いつのまにかこのようなメソッドができてしまうことが良くあります。
上記の例では getNow は単純に class A と無関係な場合であり、
getSum は class A との関係は一応あるのだけど、その関係が引数でおこなわれている、
という場合です。

こういう類のメソッドが増えるのは、なにかの危険(?)な兆候だと思います。
ただ、その危険性を明示する上でも、私は、
とりあえずやみくもでよいので static にできるものは static にしてしまいます。
＃で、あとで static のものは要注意、という位置付けでコードレビューします。
ただ、どう「危険」なのかや、本当に「危険」なのか、などは私も良く分かりません。

ちなみに static なメソッドが static なフィールドを操作するのかしないのか、
は大きな分かれ目だと思いますが、
そもそも static なフィールドを操作するメソッドは
static にするかどうか迷うことはない(static にしかできない)ので、
ここでは static なフィールドを操作しないものに限定して書きました。
H2
ぬし
会議室デビュー日: 2001/09/06
投稿数: 586
お住まい・勤務地: 港
投稿日時: 2003-05-04 08:48
引用:

unibonさんの書き込み (2003-05-03 09:23) より:
unibon です。こんにちわ。

...略...
コードを書いていると、いつのまにかこのようなメソッドができてしまうことが良くあります。
...略...
こういう類のメソッドが増えるのは、なにかの危険(?)な兆候だと思います。ただ、その危険性を明示する上でも、私は、とりあえずやみくもでよいので static にできるものはstatic にしてしまいます。

「いつのまにかこのようなメソッドができてしまう」のは危険ですねぇ・・・。きちんとデザインをしていればpublicなメソッドを作ることにおいてはそれはありえまえん。ご存知のように行き当たりばったりは、「複雑さ」が上がり、「保守性」が下がります。

確かに私がコーディングする時に「これは必要かもしれない…」と多々ありますが、その時にはきちんとデザインを見直して軌道修正をしてからやります。

コード:
public Date getNow() {
    return new Date();
}

ここら辺は個人的な好き嫌いがあると思うのですが、私個人で思うにgetNow()はstaticとしてもあるべきではないですよね。

まず普通のメソッドは、「そのオブジェクトに対する操作を提供するべき」であると思います。getNow()のように、オブジェクトのデータをまったく触らないものはメソッドして公開するべきではありません。

staticとしても、（Utility的なオブジェクトをまったく作らないClassは別として）Classに関係するものを作るべきです。私はstaticというのは、「クラスに対して処理される操作」と考えているので、その特定のClassと関係ないときには作りません。いきなり関係のないstaticなメソッドが現れた場合他の人が「これは何？？？」と悩みそうなので、私は(絶対と言っていいほど)やりません。

解決としては、別のUtility Classにstaticメソッドとして作ります。これなら別のところでも使えるのでコードの再利用化が「分かりやすく」できます。

コード:
public int getSum(A a0, A a1) {
    return a0.get() + a1.get();
}

前も言ったとおりに、「そのオブジェクトに対する操作を提供するべき」ですので、できればこういう風に書き換えるべきでは？
コード:
public int getSum(A a) {
    return this.get() + a.get();
}

これなら、あるオブジェクトに対する操作になります。特にstaticにするかどうかのジレンマに悩まされません。

＃java-houseでも似たようなディスカッションがありましたよね。
1|2|3|4|5|6|7 次のページへ»

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