- PR -

JAVAにおけるstaticメソッド

«前のページへ 1|2|3|4|5|6|7 次のページへ»
投稿者投稿内容
北斗のポン
会議室デビュー日: 2003/05/02
投稿数: 17
投稿日時: 2003-05-06 11:23
皆さん貴重なご意見ありがとうございます。

今日、連休明けで三日ぶりにアクセスしてみたら新しい投稿があったのでじっくり読ませていただきました。

私の考え的には結構unidonさんに似ているかもしれません。あ、でも「とりあえずstaticにする」というわけではありませんが・・・

例えば、日付を任意のフォーマット形式で成型されたStringで返してほしい時などは

コード:
    public static String getTime(String format) {
        {必要な処理}
        return str;
    }
(省略しすぎでしょうか？)


というメソッドを持ったUtility.classがあると便利だと思うのです。ただ、zaxx_MDさんのおっしゃる通りstaticなメソッドが増えるとモデリングが適切に行われなくなるというのも納得ですし、かといってこういった「便利機能」をまとめたクラスをインスタンス化するのもコストを考えると合理的でない気がします。

Utility.classは他にもstaticな「便利機能」がまとまっていると仮定します。こういったクラスは修正したほうがいいのでしょうか？また、修正するとしたらどういった実装方法が合理的なのでしょうか？


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
結局「そのプロジェクトにあわせた臨機応変な対応」が必要なのでしょうが（頑固な僕にはこれが一番難しいのかな）やはり自分の中で「柱」となる考え方がほしいですね。
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2003-05-06 14:20
>staticなメソッドが増えるとモデリングが適切に行われなくなると
＃モデリングじゃなくて設計では？

>Utility.classは他にもstaticな「便利機能」がまとまっていると仮定します。
>こういったクラスは修正したほうがいいのでしょうか？
ケースバイケースだと思います．

小さなプログラムで，その便利機能が3〜5個程度なら大した問題にも
ならないでしょう．大きなプログラムで便利機能が数百にも登れば大抵
分割するでしょう．

一般に副作用がないものについては問題が発生しにくい．これに対し
副作用があるものについては，設計を変える必要も高くなるでしょう．

もちろん，他の様々な条件で変わるものです．設計というのは
実に奥の深いものなので，唯一の正解というのは通常ないと思います．
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2003-05-06 15:57
>「俺流モデリングinJava」とか出版したら印税で食べていけるかな・・・
>文才無いから無理か
その前に，今の日本ではたとえ名著を出しても儲かるかどうか．．．．
世界でも最も勉強しない国と言われるのは伊達じゃない．
ギャラが印税という形になるかも疑問．

所詮は書籍執筆なんてボランティアみたいなもんです．
金儲けが目当てなら他の仕事を強くお勧めします．
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2003-05-06 17:48
>>staticなメソッドが増えるとモデリングが適切に行われなくなると
>＃モデリングじゃなくて設計では？
モデリングです。

モデリングされてない設計でも設計と呼ばれていると思います。

モデリングに関して本当に認知されてないことが残念です。
未記入
ぬし
会議室デビュー日: 2002/03/28
投稿数: 255
投稿日時: 2003-05-06 18:22
>モデリングです。
>モデリングされてない設計でも設計と呼ばれていると思います。
あ，それはモデリング中心主義者とでも言うべき世界の話ですね．
そういう流派みたいなものがあるのは知っています．

ただ役に立つと思ったことがないだけ．
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2003-05-07 14:34
＞ただ役に立つと思ったことがないだけ．

そういう人たちは無駄な多重コードを個々人で作って生産性向上とはかけ離れた世界で暮らしているんでしょうね。

私はそういう人たちとビジネスしたくないです。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2003-05-07 19:07
unibon です。こんにちわ。

引用:

H2さんの書き込み (2003-05-04 08:48) より:
前も言ったとおりに、「そのオブジェクトに対する操作を提供するべき」ですので、できればこういう風に書き換えるべきでは？
略
これなら、あるオブジェクトに対する操作になります。特にstaticにするかどうかのジレンマに悩まされません。

私が出した例が、良くなかったか、あるいは、網羅しきれなかったかもしれません。
上記のご指摘を受けて考えてみましたが、
getSum の例としては私が最初に挙げた例では、引数が2つの場合でしたが、
別の例としては、たとえば引数が List のような場合
コード:
public int getSum(List aList) {
    int sum = 0;
    for (Iterator it = aList.iterator(); it.hasNext(); ) {
        A a = (A) it.next();
        sum += a.get();
    }
    return sum;
}

のようなものは、この操作が特にどのひとつのインスタンスと結びつくわけではないので、
static なメソッドにしたほうが良いと思います。

また、最初の例で挙げたもうひとつのメソッド getNow は、これとは逆に、
たまたま操作するフィールドの数が 0 個であるだけであり、
実際は A のインスタンスと密に関連する操作である可能性もありえるかもしれません。
＃getNow の例では、無関係な日付を連想させるので、適切ではありませんでしたが。
そういうものはむやみに static にすべきではないのかもしれません。
＃たとえで言えば C で malloc(0) をどう扱うかみたいな話題に近い(雰囲気を伝えるためだけのたとえです)?

ただ、思うのですがメソッドを修飾するのに static だけでは足りないような気がします。
static なフィールド(クラス変数)を操作するメソッドか、
そうでなくてただのユーティリティのメソッド(これは static なフィールドを操作しない)か、
を区別できるような仕組みがあってもよいかな、と思いました。

あと、話は変わりますが、
ユーティリティなクラスをひとつ作ってそこになんでも詰め込んでしまうと、
肥大化してしまい、のちの取り扱いが難しくなってしまうような気もします。
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2003-05-08 11:20
こんにちは。

リストで実装されるのでしたら
引用:

public int getSum(List aList) {
int sum = 0;
for (Iterator it = aList.iterator(); it.hasNext(); ) {
A a = (A) it.next();
sum += a.get();
}
return sum;
}


これも一つの方法ですが、適切なモデリングとは思えません。
AListのようなクラスを定義して
コード:
class AList extends ArrayList {
...

public int getSum() {
    int sum = 0;
    for (Iterator it = iterator(); it.hasNext(); ) {
        A a = (A) it.next();
        sum += a.get();
    }
    return sum;
}
...
}


などとすべきではないでしょうか？
«前のページへ 1|2|3|4|5|6|7 次のページへ»

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