13/06/24 03:10:04.34
>>245
プログラミングとは関係のない話題は↓が適切
Java Runtime Environment Part3
ｽﾚﾘﾝｸ(software板)
247:デフォルトの名無しさん
13/06/24 03:38:45.47
>>246
ありがとうございます
248:デフォルトの名無しさん
13/06/24 06:46:02.07
private List<String> strList = new ArrayList<String>();
public void addString(String str) {
strList.add(str);
}
public String getString(int num) {
if(strList.size() < num+1) return null;
return strList.get(num);
}
のような、StringのListを管理するがそのList自体は返さないようなManagerクラスがある場合、
getString(int num)メソッドの一行目に書いたようにnullを返してもいいのかな？
でもこれって上で書いたようにNullPointerExceptionでエラー出すか、この一行は書かずにArrayIndexOutOfBoundsException出すかの違いでしかないのか・・・。
こういう時に何を基準に判断していくべきなのかがもう一つわからないです。
加えて、このnullチェックはメソッドを呼ぶ側ですべきなのかこのクラスでするべきなのかの判断基準もわかり辛いです。
JavaのSDKみるに、基本放置でエラー吐かせて、必要ならば呼ぶ側でする感じかなとは思いますが。
249:248
13/06/24 06:49:19.61
あぁ、String型でやったのは大きなミスだ。
これじゃヌルポはでないか。
250:デフォルトの名無しさん
13/06/24 06:49:33.15
>こういう時に何を基準に判断していくべき
このプログラムについてのお前の設計思想
>JavaのSDKみるに、基本放置でエラー吐かせて
んなこたーない
251:デフォルトの名無しさん
13/06/24 06:57:53.65
>>250
だから設計思想を形作る判断材料のどこに重点をおくべきなのかがわからないの。
お前の設計思想なんていいだしたらメモリさえ食わなきゃ何でもokみたいな言語に成り下がるわけで。
null checkもお前の設計思想では片付かない相当大きな論争がありますよね？
252:250
13/06/24 07:27:37.24
>お前の設計思想なんていいだしたらメモリさえ食わなきゃ何でもok
そうだよ。
プログラミングが目的じゃなくてコンピューターに
やらせたいことがあるんだからプログラミング言語がある。
生産性・保守性・拡張性・再利用性の様々な観点で
今回の自分の目的に叶っていれば問題なし。
プログラミング自体が目的のアホな論争など
どうでもいい
253:デフォルトの名無しさん
13/06/24 08:13:55.37
>>252
結局何も言ってないのと同じこと
254:デフォルトの名無しさん
13/06/24 08:24:23.76
いや、俺は>>250に一票。
結局のところ、プログラム全体としてのエラーや例外のポリシーを決めないとどうすべきか
なんて言えないよ。
255:デフォルトの名無しさん
13/06/24 08:43:53.04
>>254
じゃあ黙ってろよ
256:デフォルトの名無しさん
13/06/24 08:45:57.24
お前らわからないくせに偉そうにぐだぐだ言いやがるよな
257:デフォルトの名無しさん
13/06/24 10:23:06.32
わかるわからないの問題かこれ？
258:デフォルトの名無しさん
13/06/24 10:57:22.99
>>257
わからないくせに偉そうにぐだぐだ言うなって言ってんだよ。
>>252なんだよこれ。バカが。
259:デフォルトの名無しさん
13/06/24 11:21:32.05
>>258
よくわかんないからもう少し丁寧に説明してくれよ
260:デフォルトの名無しさん
13/06/24 11:22:38.82
粘着しだした
261:デフォルトの名無しさん
13/06/24 11:25:21.21
>>248
「自分的にこうあるのがベター」って考えがとくに無いなら、
とりあえずJavaの標準ライブラリに合わせりゃいいじゃん。
小難しいこと考えずに、
public String getString(int num) { return strList.get(num); }
だけで、標準ライブラリの設計と合致するっしょ。
設計思想無しにヘタに、
if (0 <= num && num < strList.size()) return null;
とか書いて例外な状況を握りつぶすのは最悪。
本当はnumの範囲外が原因なのに、
戻り値を最初に使った場所でヌルポが出るとか、原因見つけるの大変だろ。
262:デフォルトの名無しさん
13/06/24 12:05:53.67
>>248
例えばOracleが公式で出してるJNIについての設計文書を読んでみるとわかる。
URLﾘﾝｸ(docs.oracle.com)
> JNI は、null ポインタまたは不正な引数型の受け渡しのようなプログラミングエラーについてチェックを行いません。
> JNI は、次のような理由からこれらの プログラミングエラーについてのチェックを行いません。
> ・JNI 関数に起こり得るすべてのエラー条件についてチェックするよう強制すると、
> 通常の (正常な) ネイティブメソッドのパフォーマンスが低下する
> ・多くの場合、このようなチェックを実行できるほど十分な実行時の情報がない
-1やnullなどのエラーコードを返か、例外を投げるかについても言及されてる
> JNI 配列アクセス関数の一部には、エラーコードを返さないが、
> ArrayIndexOutOfBoundsException または ArrayStoreException をスローするものがある
この文章からわかるのは、
ライブラリがエラーチェックをどこまで行うのかは「ライブラリの目的によって変わる」ということ。
JNIは引用文に書かれている理由でエラーチェックを行っていないが、
もちろんこれがあらゆるライブラリに当てはまるわけではない。
263:デフォルトの名無しさん
13/06/24 12:17:59.16
>>261
getStringでnullが返ってくることが例外なのか意図された状況なのかも>>248のコード片だけじゃわからないからね
例えば配列は用意した分にしかアクセスできないけど、
用意しなかった分には任意の初期値を用意した無限のインデックスでアクセスできる配列クラスを作りたいとか
そういう場合に初期値としてnullを用意したという状況ならば、getStringでnullが返ってくることは例外ではなく正当な結果だし
>>248がそういうライブラリなのか、そうじゃないライブラリなのか絞り込むための材料は用意されていない
よって回答者のレスが抽象的・一般的になってしまうのは、そもそも用意されてるコード片が抽象的すぎて何も言えないからなんだよ
264:デフォルトの名無しさん
13/06/24 12:30:33.95
> JNI は、null ポインタまたは不正な引数型の受け渡しのようなプログラミングエラーについてチェックを行いません。
これは意味が違うだろ。
JNIというフレームワークとしては自動チェック機能を提供しないだけで、
JNIのCプログラムがnullチェックしなかったら確実に死ぬ
265:デフォルトの名無しさん
13/06/24 12:49:58.68
>>248のダメな点
・return nullだと、strListの中に入っている正当な値としてのnullが返って来たのか、
numがインデックスの範囲外であることを示すためにnullが返って来たのか区別することができない
・addStringにおいてnullチェックが行われていないため、
Listの値としてnullを受け入れるのが正当な仕様であるように見える（これでいいのか？）
↓
これらを総合すると、任意のインデックスを受け取って値を返し
初期化されてないインデックスが指定されたら初期値としてのnullを返すようなListを作ってるようにしか見えないが
これでいいのか？
266:デフォルトの名無しさん
13/06/24 13:14:57.75
>>263
>>248のコードをよくよく読み直したら、だんだん解らなくなってきた…
>>265に加えて、
・strListは参照が可変でいいの？
・負の引数はエラー、正はOK、ただしInteger.MAX_VALUEはエラー
たぶん、
「初心者は難しいこと考えずに、まずは教科書よく読んで、
しっかりコード書いて1歩ずつ理解していくと良いよ」
ってのが>>248にとって一番しっくりくる回答だと思う。
267:デフォルトの名無しさん
13/06/24 13:53:06.36
>>266は無視しておｋ
こいつ、レスつけてる連中の中で一番腕が悪い、もしくは馬鹿。
論点を無視した指摘に、意味のないアドバイス。
なんでこんな奴がドヤ顔でレスしてんの？
268:デフォルトの名無しさん
13/06/24 15:42:05.39
人を馬鹿呼ばわりすると中傷と言われますよ。
こういうときは
× >>267は馬鹿
○ >>267のレスは馬鹿な内容だ
と言うものです。
269:デフォルトの名無しさん
13/06/24 16:40:23.09
twitter botを作成しようとしてます URLﾘﾝｸ(gomyownway.hatenablog.com)
このページを参照して一応必要なキーなどな入れているのですが
Exception in thread "main" java.lang.NoClassDefFoundError: test/TweetTest のエラーがでて実行できませんどうすればいいですか？
270:デフォルトの名無しさん
13/06/24 16:52:52.97
>>269
ソースコードではなく実行環境の問題
どういう環境で実行してるのか書け
271:デフォルトの名無しさん
13/06/24 16:59:28.46
>>270
実行環境はmacでeclipseです
272:デフォルトの名無しさん
13/06/24 17:02:27.39
>>269
まず画面にtestと表示するだけのプログラムを
完成させて出直せ
273:デフォルトの名無しさん
13/06/24 17:04:18.55
>>272
それはもうやりました
274:デフォルトの名無しさん
13/06/24 17:09:41.01
>>273
プロジェクトの設定をどこかおかしくしたのが原因
だから空のプロジェクト作り直して順番に確認していけ
275:デフォルトの名無しさん
13/06/24 17:32:01.23
>>274
ありがとうございます
言われた通りに最初からやったらうまくいきました
276:248
13/06/24 22:02:44.02
return null;
の部分を
throw new NullPointerException();
にするなんていうのはなし？
277:デフォルトの名無しさん
13/06/24 22:33:14.84
上の回答見てまだそんなこと言うか
278:デフォルトの名無しさん
13/06/25 07:58:37.22
ヌルポを自分でスローするとか
どんだけお前はアホなんだよ
呼び出し側のパラメーター異常は
IllegalArgumentExceptionだろ
279:デフォルトの名無しさん
13/06/25 08:00:21.97
途中で送信したoops!
ノーチェックかチェックしてIllegalArgumentException
スローするかどちらかにしろ
280:デフォルトの名無しさん
13/06/25 10:09:07.50
そうか
なぜかreturn null前提で考えてた
281:デフォルトの名無しさん
13/06/25 14:58:19.28
質問：変数paramがユーザー指定の文字列の場合、これってコードインジェクションされる可能性あります？
String base = "ping ";
int ret = Runtime.getRuntime().exec(base + param).waitFor();
ぱっと見た目やばそうなんだけど・・・
282:デフォルトの名無しさん
13/06/25 15:15:08.63
うん。
283:デフォルトの名無しさん
13/06/25 15:22:35.69
ですよねぇ・・・
実際セミコロンつけてコマンド連ねてみても動かないから、証明出来なくて困ってる
なにまちがえてんだろ
284:デフォルトの名無しさん
13/06/25 15:27:35.39
コマンドインジェクションはむずいんじゃないのかな。
JavaのRuntime.execはシェルを呼ばない。単純に文字列をトークンに分割して
最初のトークンで指定されたコマンドに以降のトークンを引数としてわたすだけ。
なので;や|、&といったシェルが解釈する文字列は機能しないと思う。
285:デフォルトの名無しさん
13/06/25 15:36:04.27
最近Java更新しようとするとウィルス対策ソフト入れようとするんだけど
286:デフォルトの名無しさん
13/06/25 16:29:27.50
>>284
なるほど、サンクスです。適当に付け足してもうごかないわけだ
しかし、チェック処理がないのがきもちわるい
作った本人が分かってたのか、分かってなかったのか、わからんな・・・
287:デフォルトの名無しさん
13/06/25 16:50:16.66
RuntimeやめてProcessBuilder使えって通達、最近来てなかったっけ？
288:デフォルトの名無しさん
13/06/25 17:04:47.01
既存のソースにコレがあったので、直した方がよくね？って話に持っていこうかと。
このためだけに触りたがらないヤツがいるので、危険度を証明したかったんだが
証明できんｗ
という夢を見た
289:デフォルトの名無しさん
13/06/25 23:00:45.63
abstractクラスをうまく使えるようになるとかなりソース綺麗になりますねぇ
Javaは設計が上手くいったときがスカっとして個人的に一番楽しい
290:デフォルトの名無しさん
13/06/25 23:05:01.54
スカはちょっと・・・
291:デフォルトの名無しさん
13/06/26 01:57:41.23
abstractとか失敗設計の典型例だろ
292:デフォルトの名無しさん
13/06/26 03:55:18.95
?
293:デフォルトの名無しさん
13/06/26 04:02:32.31
>>291
これはひどい
294:デフォルトの名無しさん
13/06/26 05:40:01.92
そもそもオーバーライドはバグの温床なのに必ずオーバーライドしなきゃダメな時点でアウト
295:デフォルトの名無しさん
13/06/26 06:53:39.61
オーバーライド以上にコードのコピペがバグの温床。
いつの日か出会うかもしれない変な継承によるバグにおびえるヒマがあったら
今目の前にあるコードから継承や抽象クラスやコンポジションを使ってコードの
反復を一つでも減らした方がまだ生産的。
296:デフォルトの名無しさん
13/06/26 07:13:47.54
>>295
オーバーライドではない→コピペ
まずこの発想がキチガイ的でヤバイ
297:デフォルトの名無しさん
13/06/26 07:24:24.63
オーバーライドはスーパークラスの呼び出しをJavaDocで指示するケースが一番ヤバイな
protectedなメソッドを空実装しといてオプショナルにしとくのなら安全で使いやすいが
298:デフォルトの名無しさん
13/06/26 07:29:01.28
> オーバーライドではない→コピペ
こういう解釈にいたる時点で日本語読解力がヤバい。
バグの温床としてオーバーライド < コピペだとは書いたけど、
オーバーライド無し -> コピペとは一言も書いていない。
299:デフォルトの名無しさん
13/06/26 12:39:13.32
コンストラクタで必ずsuper()を呼び出さないとアカンやつ大杉や！
300:デフォルトの名無しさん
13/06/26 14:45:51.34
オーバーライドがバグの温床なんていうのはいいすぎじゃないかな
依存関係からいっているのかな、だけど普通abstractクラスはそれを分散させないために使うんじゃない？
例えば描画と更新が必要なGUI開発やゲーム開発とかで
ArrayList<MyObject> objects = new ArrayList<MyObject>();
public void update() {
for(MyObject mo : objects) mo.update();
}
public void render() {
for(MyObject mo : objects) mo.render();
}
のように描画する対象物がどんな形でどんな役割であろうと同一化したほうがスッキリする場合、
abstract class MyObjectにして座標等のフィールドはprotectedにする。
で、update()メソッドもabstractにしてrender()に関しては場合による。
以降はMyObjectクラスを継承したMOBoxクラス、MOBarクラス、MOMenuクラス、
ゲームならMOPlayer、MOEnemy・・・
といったように本来の役割が違ってもかなり深く抽象化できて扱いやすいことは多いよ。（SwingのJComponentクラスがまさにこれだよね）
Decoratorパターンも導入しやすいですし。
301:デフォルトの名無しさん
13/06/26 20:09:38.19
たとえ具体クラスが一つしかなくたって、
ふくれあがった唯一神クラスを分割記述するためだけに
abstract使ってもいいのよ？
302:デフォルトの名無しさん
13/06/26 20:13:28.83
そもそも、目的にあった道具を使うもんじゃないかな。
勝手な想像だが、 >>291 は、道具の使い方や、使う場面を間違えてるんじゃないかと思う
カラフルな絵を書くのが目的のときに、
「黒しか出ないってなんだよ、エンピツつかえねぇ！」
↓
「エンピツ使うとか失敗するにきまってるだろ」
って言ってるように聞こえる。
303:デフォルトの名無しさん
13/06/26 21:07:21.54
インターフェースを定義した後にロジック実装の骨格を提供するのにも使うな > abstract
単にabstractを使う機会が無かっただけじゃない？
304:デフォルトの名無しさん
13/06/26 22:19:30.43
>ふくれあがった唯一神クラスを分割記述するためだけに
>abstract使ってもいい
意味や機能でなく
処理でクラスやメソッドを分けるのは
JAVAドカタの得意技だね
305:デフォルトの名無しさん
13/06/26 22:35:34.39
ロジック実装して初めてインターフェースは見えてくるもの
それがわかってないからたいてい抽象化が無意味になって失敗する
だいたい考慮すべきことが多いのに最初から一発OKな設計になるわけない
・引数にするか、メンバーにするか
・使うのはここだけか、何度も使うことになるか
・・・
306:デフォルトの名無しさん
13/06/26 22:39:41.25
>>305
>ロジック実装して初めてインターフェースは見えてくるもの
それはお前がドカタだから。
設計のできる人はそんなこと無いから。
307:デフォルトの名無しさん
13/06/26 22:51:51.03
処理によってクラスやメソッドを分けるのは当たり前じゃ？
それに違和感を感じるのはクラス分けると書けないいわゆるオブジェクト指向になれてない人か、
デザインパターンすら認めない？生きた化石じゃないか？
仕事を割り振ることを考えたらabstractが設計失敗なんてありえないと思うよ。趣味でやってるレベルでもわかる。
>>305
＞だいたい考慮すべきことが多いのに最初から一発OKな設計になるわけない
同意だけど、abstract等で縛っていかないから抽象化が失敗するんだと思う。
＞ロジック実装して初めてインターフェースは見えてくるもの
これを念頭に置くのは大反対。
抽象化しすぎると将来どうなるかわからないからpublicにしとけ的な設計が一番ダメに感じる。
見えてこないのはまさに修飾子を正しく把握していない、もしくは縛って自由を獲得する設計に慣れていないだけ。
308:デフォルトの名無しさん
13/06/26 22:56:42.35
>処理によってクラスやメソッドを分けるのは当たり前じゃ？
いやー、JAVAドカタって
ほんっっとにどうしようもないな
309:デフォルトの名無しさん
13/06/26 22:57:04.78
「このクラスについて詳しく見たわけじゃないけどこのクラスもあのメソッド使えそうだな」
これ、誰でもAPIで経験してるはず。
設計さんに感謝やで。
継承がバグの温床なんていったらバチあたるでほんま。
310:デフォルトの名無しさん
13/06/26 23:23:04.49
抽象クラスがなかったらコールバック関数に渡す無名インナークラスとかどうするんだよ
311:デフォルトの名無しさん
13/06/27 00:40:03.70
うむ。RCP息してない。
312:デフォルトの名無しさん
13/06/27 01:40:13.43
>>286
そういやそのへんの挙動、最近のupdateで何か変わってなかったっけ。
記憶違いかも知れんが。
313:デフォルトの名無しさん
13/06/27 01:40:54.77
処理によってクラス分ける利点は静的に扱うときに一番あらわれる気がする
動詞をクラス名にしたりね。
314:デフォルトの名無しさん
13/06/27 01:43:54.45
List<Object> list = new ArrayList<Object>();
みたいな書き方って海外の人あまりしないよね？なぜ日本ではこれが推奨されているの？
315:デフォルトの名無しさん
13/06/27 01:56:34.66
Javaのジェネリクスは保守的でコードレベルでタイプセーフにするだけだからな
Java8だかでインタフェースのメソッドがステートレスに実装可能になるらしいから驚き
316:デフォルトの名無しさん
13/06/27 02:17:56.80
>>314
海外ではどんな書き方なん？
317:デフォルトの名無しさん
13/06/27 02:27:14.62
>>316
普通に
ArrayList<Object> list = new ArrayList<Object>();
って書く人が多いように思う。
自分もそう書いていたんだけど
List<Object> list = new ArrayList<Object>();
のほうがいいよ的な意見もよく聞く。
だけどそういう人でも
JComponent button = new JButton();
ってのは書かずに
JButton button = new JButton();
と書く人が多い。
なぜArrayListのときはそういう書き方をするのか教えて欲しい。
318:デフォルトの名無しさん
13/06/27 02:38:07.98
>>317
意味論的にそれが有効だからとしか。
ArrayListはランダムアクセス可能なList
JButtonはSwingのボタンUIとして確固たる知名度と意味を持つ
てかJComponentは抽象度が高すぎるしね
319:デフォルトの名無しさん
13/06/27 02:40:12.03
そもそも前と後ろ同じじゃないとなんか感覚的に見た目気持ち悪いんだがどうなん
320:デフォルトの名無しさん
13/06/27 02:45:07.10
宣言側はアプリケーションで必要とされている意味論的に適切な抽象度で宣言する
生成側はパフォーマンス特性に合わせて無難または最適な物を生成する
321:デフォルトの名無しさん
13/06/27 02:46:01.29
>>314
こういうのってキャストとかしなくて大丈夫なん？
322:デフォルトの名無しさん
13/06/27 02:48:56.11
ArrayList (Java Platform SE 7)
URLﾘﾝｸ(docs.oracle.com)
通常、リストの同期をとるには、リストを自然にカプセル化するオブジェクトで同期をとります。
そのようなオブジェクトが存在しない場合は、Collections.synchronizedList メソッドを使用してリストを「ラップ」する必要があります。
これは、リストへの偶発的な非同期アクセスを防ぐために、作成時に行うのが最適です。
List list = Collections.synchronizedList(new ArrayList(...));
323:デフォルトの名無しさん
13/06/27 03:07:49.08
>>322
マルチスレッドでadd()等の処理をするときに同期どれよというのはわかってけど
まるで答えになってないよね？
324:デフォルトの名無しさん
13/06/27 03:15:37.97
The List Interface (The Java? Tutorials > Collections > Interfaces)
URLﾘﾝｸ(docs.oracle.com)
Here's a nondestructive form of this idiom, which produces a third List consisting of the second list appended to the first.
List<Type> list3 = new ArrayList<Type>(list1);
list3.addAll(list2);
325:デフォルトの名無しさん
13/06/27 03:20:07.47
>>321
オブジェクト指向言語で抽象度の高い方向（スーパーセット）にキャストするのは問題ない
ここら辺は個別に疑問を持つより基本を一通り知ってから考えた方がいいよ
326:314
13/06/27 03:41:15.24
>>324
そこじゃなくない？外国人が使っているよということを言いたいの？何が言いたいの？
リンク先で、
同じオーダー中に同じ要素を含んだ二つのListが等しくなるってのはわかった。
で、equals書くならhashCodeも一緒に書けよっていう某本にも書いてるその辺にも強いことがわかった。
これが答え？
327:デフォルトの名無しさん
13/06/27 06:21:34.84
外国・・・そうかなぁ? 個人的には>>320に同意。
例えば適切な抽象度のインターフェイスが別にあるのにArrayListとかHashMapと
いった実装クラスを引数として要求したり返値として返したりする公開メソッド
を持つクラスに出会った場合は、とりあえずその品質を疑ってかかる。
いわゆる「臭う」コードのよくあるパターンだと思う。
内部変数にしても例えばArrayList使って抽象度を下げるとListのような抽象度の
高い引数を受けにくくなるので、こちらも普通はListを使うかな。
ある場所での型の抽象度の低さはコード中の他の場所に伝染するんだよね。
328:デフォルトの名無しさん
13/06/27 06:40:22.65
>>318
その理屈はおかしい
JavaのListはランダムアクセスが効率的に行えることを保証しないので、
ランダムアクセスしたいならArrayListで受けなければならないということになってしまう
いや意識してそういう理由でArrayListならそれでいいと思うけどね
ジェネリクスでList,RandomAccessとする手もあるけど
内部でnewする変数にそこまでするのは現実的じゃないわな
329:デフォルトの名無しさん
13/06/27 06:56:02.07
>>325
ただしそれはオーバーライドがない時の話な
オーバーライドされたメソッドがある場合は派生クラスが厳密に規約を守っているか確認しなければ規定クラスとして使ってはいけない
オーバーライドしているとたやすくis aの関係が破壊される
規約を作れば良いというがその規約にバグがないことも規約が守られてることも保証することは難しく人の注意力に頼るしかない
だからバグが量産される
た
330:デフォルトの名無しさん
13/06/27 07:06:20.79
ListってまともにListIteratorで操作されてることは滅多にないよね
ランダムアクセスのためのインターフェースとしなかったのはJavaの大失敗の一つ
331:デフォルトの名無しさん
13/06/27 12:01:34.71
List をランダムアクセスにしたら LinkedList が List じゃなくなるじゃないですか
名前的に紛らわしい
332:デフォルトの名無しさん
13/06/27 13:37:26.26
予期せぬListの実装が引数に渡されたらどうなっちゃうの？
333:デフォルトの名無しさん
13/06/27 14:51:40.48
java.util.RandomAccessに代入可能かどうかで判定するのが
業界の慣習。一応。
334:デフォルトの名無しさん
13/06/27 15:20:23.50
String戻せば済むところをCharSequence返すメソッドは考えすぎだと思う。
メソッド引数としてはアリ
335:デフォルトの名無しさん
13/06/27 21:25:21.75
>>334
Androidの真似して
かっこいいと勘違いしたんだろ
336:デフォルトの名無しさん
13/06/27 23:59:50.59
StringBuilder返すところでホントはAppendable返したいのだが
IOExceptionがじゃまなの…
337:デフォルトの名無しさん
13/06/28 01:16:49.31
>>331
.NETはまさにそうなってるね
名前的には残念なことになってるが設計としてはアレが正解だわ
338:デフォルトの名無しさん
13/06/28 01:20:26.99
>>329
その話、アップキャスト関係なくね？
339:デフォルトの名無しさん
13/06/28 03:30:45.63
private int a;
private int b;
private int c;
public Constructor(int a, int b) {
this.a = a;
this.b = b;
// 引数a, bできまるcはこう書くべきなのか
c = a+ b;
// こう書くべきなのか、どっちがいいですか？
c = this.a + this.b;
// やはり前者？
}
340:デフォルトの名無しさん
13/06/28 03:40:28.29
>>339
前者にすべき。マルチスレッドに対応させる際に後者だと都合が悪い
341:デフォルトの名無しさん
13/06/28 04:03:42.53
>>340
把握しました
342:デフォルトの名無しさん
13/06/28 04:14:49.32
横レスだけど
後者だとどう都合が悪いの？
343:デフォルトの名無しさん
13/06/28 07:05:24.68
問題ないよ
344:デフォルトの名無しさん
13/06/28 07:30:16.62
>>340
最悪な回答だな
345:デフォルトの名無しさん
13/06/28 07:33:43.35
どっちでもいいだろ
コンストラクターが完了するまでは
オブジェクトの構築が終わってないんだから
他のメソッドに合わせてthisを使う必要はない
346:デフォルトの名無しさん
13/06/28 08:59:23.11
>>342-345
マルチスレッドにした場合は初期化中のオブジェクトにアクセスされる可能性がある。つまり
this.a = a;
this.b = b;
// ここでthis.aやthis.bの値が別スレッドから更新される可能性もある
c = a+ b;
その結果「引数a, bできまるc」という仕様が満たされないことになる
c = a+ b;なら別スレッドから何かされても仕様は満たされるが、
c = this.a + this.b;にした場合は、初期化中のオブジェクトが外部に公開されて
this.aやthis.bが変更される危険がないかConstructorクラス全体を調べなければならない
どちらの方が安全にコーディングできるか考えれば答えは明らかだよね
347:デフォルトの名無しさん
13/06/28 10:30:31.07
>>346
Java言語仕様読み直せ
348:デフォルトの名無しさん
13/06/28 10:36:23.41
>>339
コメントに沿った実装という意味では前者だな。
意味的にも前者のほうがいいんじゃなかろうか、そのコード片だけでは判断できんけど。
結果はどっちも変わらん。
349:デフォルトの名無しさん
13/06/28 10:41:16.57
cが引数a,bから決まるのでなくメンバのa,bから決まる値の場合は・・？
350:デフォルトの名無しさん
13/06/28 10:48:00.80
どこで>>346みたいな知識を仕入れたのか気になるんですが...
検証の仕方も思い浮かびません...
351:デフォルトの名無しさん
13/06/28 10:50:51.90
コンストラクタってスレッドセーフじゃないん？
352:デフォルトの名無しさん
13/06/28 10:51:08.41
>>349
その場合はそりゃ後者だろう。
353:デフォルトの名無しさん
13/06/28 10:52:26.29
The Java? Tutorials
URLﾘﾝｸ(docs.oracle.com)
JAVA覚えようぜ
354:デフォルトの名無しさん
13/06/28 11:37:29.87
>>346の謎解きをするスレはここですか？
>初期化中のオブジェクトが外部に公開
コンストラクタで外部にthis参照が逸出するときのことを言ってるんだろう。
ふつう、コンストラクタはthis参照を外部に公開しないように実装するものなんで、
そういう状況になること事態が実装上の不備だと思う。拙者そう思う。
355:デフォルトの名無しさん
13/06/28 12:26:37.11
コンストラクターがマルチスレッドって
ただのコーディングミスだろ
356:デフォルトの名無しさん
13/06/28 12:43:30.30
>>354
でもそれだとマルチスレッド関係ないよな...
357:354
13/06/28 12:50:39.56
>>356
俺はマルチスレッドの話をしたつもりだったんだが、お前はなんで俺の話がマルチスレッドと関係ないと思うの？
358:デフォルトの名無しさん
13/06/28 13:15:22.64
double checked locking 問題ではコード読んだ時の直感に反して
コンストラクタ完了前に参照漏洩してたりしたからなぁ。
あの手の問題あるとチェックしきれん。
359:デフォルトの名無しさん
13/06/28 14:28:50.08
>>357
シングルスレッドでも逸出させられる
360:デフォルトの名無しさん
13/06/28 14:38:54.68
B木を実現するjavaプログラム、難しいけどわかる人いますか？
361:桃白白 ◆9Jro6YFwm650
13/06/28 14:45:17.44
>>360
桃白白わかるよ。
362:デフォルトの名無しさん
13/06/28 15:01:04.41
スレッドAが生成した新オブジェクトを
ロック無しで確実にスレッドBに届ける方法は無く、
スレッドAがロックすれば確実に初期化された新オブジェクトが
全スレッド間で共有されてしまうので
正直 ど う で も い い
363:デフォルトの名無しさん
13/06/28 15:04:35.49
自分も前者がいいな。10文字少ないので。
364:デフォルトの名無しさん
13/06/28 15:06:40.22
>>361
すみません、教えてください。
365:桃白白 ◆9Jro6YFwm650
13/06/28 15:09:21.89
>>364
B木のなにを知りたい？アルゴリズム？インプリメンテーション？
値を追加するところ？値を削除するところ？値を検索するところ？
どのあたり？
366:デフォルトの名無しさん
13/06/28 15:15:09.70
>>350-351
TSM01-J. オブジェクトの構築時にthis参照を逸出させない
URLﾘﾝｸ(www.jpcert.or.jp)
367:デフォルトの名無しさん
13/06/28 15:16:16.75
>>365
値の追加、検索、削除が出来ればOKです
初めに任意で最大の子の数を入力する所から始めたいです
368:桃白白 ◆9Jro6YFwm650
13/06/28 15:34:04.09
>>367
コード欲しいってことね。
桃白白もいくつかコード眺めてみたけど、奥村さんのコードが一番きれいだと思う。
『Javaによるアルゴリズム事典』サポートページ
URLﾘﾝｸ(oku.edu.mie-u.ac.jp)
369:デフォルトの名無しさん
13/06/28 15:50:38.71
>>368
ここに置いてあるzipファイルの中の「BTree.java」ですよね？
ありがとうございます！これを参考にします。
370:桃白白 ◆9Jro6YFwm650
13/06/28 15:55:43.37
>>369
はい、それです。
371:デフォルトの名無しさん
13/06/28 20:15:07.51
JavaScriptは板違い
ローカルルール読んでこいよ異常者共
372:デフォルトの名無しさん
13/06/28 20:39:57.59
自作クラスの感想などを頂きたいのですが、スレ違いでしょうか？
373:デフォルトの名無しさん
13/06/28 20:42:02.65
相談のうちには入る…のかなあ
374:桃白白 ◆9Jro6YFwm650
13/06/28 20:49:48.68
>>372
いんじゃないの。書いちゃいなよ。
375:デフォルトの名無しさん
13/06/28 21:26:55.04
>>374
自分のコードの感想言われたらファビョる奴が良く言うよ
376:372
13/06/28 21:27:03.75
ソースファイルが６つあるので、こちらにアップしていて遅くなりました。
URLﾘﾝｸ(sourceforge.jp)
コーディングを補助する目的で作った文字列テーブルです。２ヶ月ほど前にJavaの勉強も兼ねて作りました。
（「TableTest.java」にとりあえずの使い方が書いてあります）
377:デフォルトの名無しさん
13/06/28 21:32:12.78
おまいらIdeoneぐらい教えたれよ
378:デフォルトの名無しさん
13/06/28 21:32:33.32
sourceforgeねぇ
379:デフォルトの名無しさん
13/06/28 21:48:31.18
>>376
System.out.println( "Table file : ファイル名を指定してください" );
return false;
のようなものは
throw new IllegalArgumentException( "Table file : ファイル名を指定してください" );
のようにしておけ
false 返しても結局戻り値チェックしないんだし、エラーを無視して実行を続けるより死ぬ方がいい
特別に理由があって死にたくないときは try catch すればいい
380:372
13/06/28 22:04:25.51
Ideoneにも上げました。Sourceforgeの方は消したいと思います。
URLﾘﾝｸ(ideone.com)
URLﾘﾝｸ(ideone.com)
URLﾘﾝｸ(ideone.com)
URLﾘﾝｸ(ideone.com)
URLﾘﾝｸ(ideone.com)
URLﾘﾝｸ(ideone.com)
URLﾘﾝｸ(ideone.com)
381:デフォルトの名無しさん
13/06/28 22:08:09.94
ideoneやcodepadは英語サイトだから利用規約や制限事項や禁止事項がわからないし、利用料金や支払い方法もわからん
382:372
13/06/28 22:32:42.03
>>379
わかりました。
引数のチェックでは throw new IllegalArgumentException を使うのが一般的なんですか？
383:デフォルトの名無しさん
13/06/28 23:49:28.98
メソッドのコメントに
//- こういうの流行ってんの？
384:デフォルトの名無しさん
13/06/29 01:37:41.96
一個目のファイルしかみてないけど、Javaな人はあれみて何も思わないの？
俺、すげー気持ち悪いんだけど。
setHead, setPrimary, set, file、全部キモい。
addとかappendとかkeyとかindexとかcolumnとかpush_backとかなんかそんな概念じゃないのか？
まあ、かろうじてinsertはありなのかもしれないが。
385:デフォルトの名無しさん
13/06/29 01:42:53.74
あと、列データとかtokenとか、一体どこ経由でこのコードにたどり着いたんだ？
386:デフォルトの名無しさん
13/06/29 02:51:57.69
突っ込みどころが多すぎる
列を追加してるのにsetHeadというメソッド addだろ
標準出力するだけのクラス tableを受け取るメソッドかtoStringに書けばいい
トリッキーなgetterとsetter 座標指定で十分
同一パッケージから直接変更し放題のフィールド 大事な値をうっかり壊しちゃうかもよ
何でもpublicメソッド エラーメッセージとか外から呼び出すの？
別のクラスに投げるだけなら直接呼び出せ
ファイルが閉じられない可能性がある
Exceptionでキャッチすんな
．．．
387:372
13/06/29 03:00:41.42
>>384-385
insertは、なぜありなんでしょうか？Javaというか、オブジェクト指向に触れて３ヶ月ほどなので、
その概念というのがちょっとわからないです・・・。メソッドの持つ役割とかですか？
列データやtokenなどは、いい加減に書いてしまいました。
ArrayListを入れ子にしているので、行列のフィールドに対するコメント文です。
388:デフォルトの名無しさん
13/06/29 05:13:45.52
>>387
慣用的に使われる用語とその組み合わせというのがあって、大抵それは求めれば他のソフトウェア
技術や数学用語にちゃんと由来が見つかる。
例えばデータ構造として表(table)という名前を使うのであれば列(column)や属性(attribute)、
行(row)やタプル(tuple)という言葉と組で使うのが慣用的。これらの用語は関係データベースの
世界に由来の一端(全てではない)があって、この世界ではrelation・attribute・ tupleかtable・
column・rowの組で使う(厳密にはこの二つの組は異なる概念なので混ぜるのも良くない)。
あとPrimary、これも元々関係データベースから来た用語だけど、数ある候補キーの中から一つ
を選んで主キー(primary key)とするのであって、PrimaryKeyならともかくPrimaryだけでは
意味をなしていない。無難なのはKeyColumnかな。
操作に関してもtableにinsertとはおぉDB的だなぁと思ったらsetと出てきてずっこける。
DB的にupdateとするとややずっこけ感は少ない気がする。
setHeadは三重の意味で良くない。一つは上記の通りheadという名前。二つ目は列の「追加」
なのにsetという用語を使っていること。最後にsetHeadというメソッド名はJava Beansの
規約でtableのheadプロパティの値をセットするメソッドに使う必要があること。
389:デフォルトの名無しさん
13/06/29 05:45:43.21
要約：クラス設計がレビューされていないような品質
390:384
13/06/29 07:41:48.98
>>388
あまりにアレ過ぎて言語化できなかったんだけど、すっきりしたよ。ありがとう。
俺、Javaは初心者なんだけど、Javaな世界ではあんな感じが普通なのかと思ったよ。
誰も何も言わないから。
391:デフォルトの名無しさん
13/06/29 08:25:23.88
名付け規約に準ずるのは当然だが、
あまりにしつこい社会主義のようだと、せっかくの創造性がつぶれる
もともと日本人には発想性がある人が少ないのに、さらに減ってしまう
ジャワみたいにばかみたいに長い名前をつけるのもどうかと思うがな
コンパイル後も短いシンボルになってないので、実行時の翻訳にムダな時間がかかる処理系もあるだろう
392:デフォルトの名無しさん
13/06/29 08:58:37.24
今のところコード品質に関する指摘は>>386だけだな
他は識別子の名前についてガヤガヤ言ってるだけで特に耳を傾ける必要はない
コーディング規約読めばそれで理解できる話だし
393:デフォルトの名無しさん
13/06/29 12:47:46.80
包含関係がしっかりしていれば長い名前空間も苦にはならないが、そうなっていない
StringとStringBufferの区別は本当に必要なのか、とか
394:デフォルトの名無しさん
13/06/29 12:52:19.11
なるほど、不変オブジェクトだけで十分、と。
395:デフォルトの名無しさん
13/06/29 12:56:03.85
可変オブジェクトだけで十分、っていう意味かもしれないじゃない
396:デフォルトの名無しさん
13/06/29 14:25:16.00
>>392
名前超大事
397:デフォルトの名無しさん
13/06/29 15:39:30.97
>>396
チーム開発なのか個人開発なのか
ライブラリとして提供するのか
色々シーンあるだろ。個人開発なのに名付け規則に神経すり減らすのはエネルギーの無駄
398:デフォルトの名無しさん
13/06/29 15:48:00.90
名前に神経すり減らすんじゃなくて
>>397みたいな奴が妥当な名前を付けられないってだけ
399:デフォルトの名無しさん
13/06/29 16:56:30.39
会社の歯車がプログラムの歯車をつくるような環境って事か
それは自由がないわな かわいそうだな．．．
400:372
13/06/29 17:19:07.84
>>386
別のクラスに投げるだけなら、といのは、ファイル入出力や画面への出力は、
同じクラスにメソッドとして持たせるという意味合いで合ってますか？
それとも、ひとつのJavaファイル内に複数のクラスを書くということでしょうか？
何でもpublicメソッドなのは、正直、アクセス修飾子の使い方をわかっていませんでした。
401:372
13/06/29 17:58:10.67
>>388
知りませんでした。メソッド名は
(setHead -> add)、(setPrimary -> setKeyColumn)、(set -> update)、(get -> select)
こういう風にすればいいですか？
402:デフォルトの名無しさん
13/06/29 17:59:31.16
> 正直、アクセス修飾子の使い方をわかっていませんでした
( ﾟдﾟ )
403:デフォルトの名無しさん
13/06/29 18:52:47.47
そもそも、コンセプトとして、いわゆるDBのテーブルを想定しているのか、Excelのシート、つまり
二次元のデータの入れ物を想定しているのかがわからない。
そういう意図を表明するという意味で、名前重要。
404:デフォルトの名無しさん
13/06/29 18:59:40.27
命名規則に話が集中しているのはそこがあまりにタコだと実装のレビューをしようにも読む方が
無駄な努力を強いられて嫌になるから。Tableクラスだけでもなかなかの忍耐が必要。
一人で書き捨てするコードならともかく、人に読んで貰うなら命名規則や慣用は要尊重。
無知を言い訳したオリジナリティーの発揮は単に有害。初心者こそ模倣から始めるべき。
・適切なクラス名やメソッド名が解らないのであれば既存のライブラリのAPIから似たような
ことをしているクラスやメソッドの名前を探して真似をする。
・適切なコメントの付け方が解らないのであれば既存のライブラリのソースコードを調べて
(クラス名に.javaとつけてググればいくらでもヒットする)真似をする。JavaにはJavaDoc
形式というコメントの付け方が定義されていて、これ以外の独自コメント形式は単に迷惑。
・適切な変数名が解らなければ既存のライブラリのソースコードを調べて(以下略)
解らなければまず調べよう。
初学者ほど何故か調べない、真似をしない、コンパイル時のエラーメッセージも読まない不思議。
405:デフォルトの名無しさん
13/06/29 19:03:01.06
クラス定義時の一般論として
・フィールドは基本private。さらにfinalに出来ないか検討する。Tableのtableなんかは
finalに出来る。finalではないpublicは御法度。protectedも慎重に。
・フィールドの型は特別な事情が無い限りHashMapといった実装クラス名よりもMapと
いうインターフェイスを用いた方が一般的に設計の抽象度が上がって実装に柔軟性が出る。
・データの重複はバグの温床なので避ける。例えばrow_no、row_sizeなんてフィールドが
用意されているけれども、table.size()等で代用できないか検討する。パフォーマンス?
それは素直で安全な実装で大敗してから考えるべき。
・特別な事情がない限りファイルIOは直接手作りしない。例えばTableクラスの場合は
write(DataOutput out)、readFields(DataInput in)というDataInput、Outputを使って
読み書きするメソッドを用意するのがお薦め。これだけでTableクラスをファイルに保存
することも、ネット経由で投げることも、Hadoopでビックデータ解析(笑)にも使える。
あるいはJAXBやJacksonを使ってXMLやJSONへマッピングする方法を検討する。
続く。
406:デフォルトの名無しさん
13/06/29 19:05:40.12
Tableクラスに関するとりあえずのコメントとして
・カラムの型や名前をバラバラのMapで管理しているのはあまり良くない。素直にカラムの
定義を扱うTableの内部クラスを用意して、
public static class Column{public final int index; public final String name; public final String type;}
これのリストをスキーマとして定義する。必要であればルックアップテーブルも。
private final List<Column> schema = new ArrayList<Column>();
private final Map<String, Column> nameToColumn = new HashMap ...
スキーマ情報を提供する公開メソッドも用意すると親切だよね。
public List<Column> getSchema() {return Collections.unmodifiableList(schema);}
public List<Column> getColumn(int index) {return schema.get(index);}
public List<Column> getColumn(String name) {return nameToColumn,get(name);}
・検索結果に一個結果を追加する度にサイズを+1した配列を生成して内容を全件コピーする
凄いコードを見たような気がするのは気のせいだよね・・・素直に可変長であるList
を使うべき。返値もListで良い。
・for(int i...)ではなく拡張for構文を使ってくれた方が読みやすい
・・・この調子で書いていくとどうなるのだろう・・・
407:デフォルトの名無しさん
13/06/29 19:15:00.14
お前のレスを読むにもかなりの忍耐が必要
408:372
13/06/29 19:31:53.15
>>406
スキーマって何ですか？
409:デフォルトの名無しさん
13/06/29 19:56:44.17
自分で調べてから質問しろ
410:デフォルトの名無しさん
13/06/29 19:58:21.58
>>408
構造の定義のことでしょ。
>>406のコードでは列情報のことっすね。いまTableにはこの列がありまっせーていう情報。
411:デフォルトの名無しさん
13/06/29 19:58:31.40
>>408
スキーマとは構造のこと。テーブルのスキーマはテーブルの構造のこと。
テーブルのスキーマは一般的には列の定義の集合で、個々の列は名前や型を持つ。
テーブルの構造をスキーマと呼ぶ一方で、具体的なデータが入ったテーブルその
ものはインスタンスと呼ぶ。スキーマとインスタンスもDBの世界で使われる言葉。
なのでDBの素養のある人であればtable.getSchema()がカラム定義のリストを返す
のは簡単に想像出来る。これが命名規約や慣用の強み。
ただschemaに関しては素直にcolumnList、getColumnListでも良いかもね。
というかこれ以上現状のコードをレビューをするのもしんどいので、一度自分で
色々調べ直して書き直したコードと共に出直してくれないかな。
412:デフォルトの名無しさん
13/06/29 20:05:52.52
どんな勉強したらこんなに酷くなるの？
参考にしたものがどうしようもないゴミか、372が変な方向に理解しちゃったの？
ちょっとjavax.swing.table.DefaultTableModelを見てみなよ
413:デフォルトの名無しさん
13/06/29 22:07:32.53
どんなレスを期待してコードを見てくれと言ってるのかわからないが、メソッド名を言われた通りに変えればOK
的なレベルに達してないから。
414:デフォルトの名無しさん
13/06/29 22:20:15.32
詳細設計書なんていらんだろ派がこの板には多いと思うが、こういうコードを見れば
必要な場合もあるということがわかるはず。
415:デフォルトの名無しさん
13/06/29 22:34:56.88
>>414
こういうコードを見ても設計何ソレ
なのがJAVAドカタの真髄
416:デフォルトの名無しさん
13/06/30 00:49:17.69
Windowsで無料でJavaを勉強出来る開発環境を教えて下さい
417:デフォルトの名無しさん
13/06/30 01:12:40.42
JDK + テキストエディタ
418:デフォルトの名無しさん
13/06/30 01:23:16.55
いるんだよなこういうジジイ発想の奴が
Eclipseと答えるのがまっとうな人間
419:372
13/06/30 02:14:52.38
みなさまのアドバイスを参考に書き直してみました
ご指導よろしくお願いします
mainクラス URLﾘﾝｸ(ideone.com)
Tableクラス URLﾘﾝｸ(ideone.com)
Columnクラス URLﾘﾝｸ(ideone.com)
420:デフォルトの名無しさん
13/06/30 02:20:15.16
>table.getAttribute(j)
これはＫＵＳＯコード
421:デフォルトの名無しさん
13/06/30 02:37:58.18
クソと言うなら理由も書け
422:デフォルトの名無しさん
13/06/30 02:49:23.64
ちゃんと差分を見てあげようよw 初めのに比べたら随分スッキリした。
その分随分機能も削られているけど。
・Columnがattributeを持つのは変。意味的にここはnameだと思う。
・せっかくColumnをimmutable(変更不可能)なオブジェクトとして定義しているのに
tableにgetTypeやgetAttributeを用意しているのは勿体ない。getColumnで直接
Columnオブジェクトを渡して無問題。table.getColumn(index).getType()みたい
に使える。
・コンストラクタにColumnの配列を渡すようにしたのは好判断だと思う。
後からColumnを追加出来ないようにするだけで他の部分のロジックが単純になる。
・ただ内部的にはColumnsは配列ではなくListで持っていた方が色々と具合が良い。
Javaの配列はimmutableに出来ない。なので例えば現状のgetAllColumnsはこれを
使って個々のColumnを差し替えることが出来るので安全ではない。
さらにコンストラクタ引数に渡したColumnsの配列は防御的コピーをすべき。
private final List<Column> columnsとして、コンストラクタで
this.columns = Collections.unmodifiableList(new ArrayList<Column>(Arrays.asList(columns)));
とでもしておくと良い。getAllColumnsでcolumnsをそのままreturnしても無問題。
・細かいことだけどコンストラクタはTable(Column... columns)の方が使い勝手が良い。
new Table(new Column(...), new Column(...))も、現状通りColumn[] columns = ...
としてnew Table(columns)とする使い方も両方使える。
・insertで入力値の型チェックも実装すると素敵だと思う。
この調子で行くとよいんじゃないのかな。
423:デフォルトの名無しさん
13/06/30 02:57:42.08
最初のコードに比べたらだいぶマシになったな
入門以前レベルから初心者レベルまで話が進んだ
424:デフォルトの名無しさん
13/06/30 03:03:45.80
> getAllRecords
Listの中身を全件配列にコピーする、そんな定番処理は手作りするまえにAPIと
して用意されていないか調べるべきだろうね。もちろん存在する。
ListのtoArrayメソッドの使い方を調べてみると良いと思う。
425:デフォルトの名無しさん
13/06/30 03:09:50.58
＞ public final void insert(final Object... record) {
finalに出来ないか検討するっていうレスがあったけどここまでする必要ない
classにfinalついてるからメソッドのfinalは全部無意味
サブクラス作れないからオーバーライドできないもん
仮引数のfinalはあってもいいけど
＞ for (int i = 0; i < table.getAllRecords().length; i++){
繰り返しの度に時間がかかるメソッドが呼ばれるけどいいの？
426:372
13/06/30 03:31:24.30
>>403
DBへの問い合わせ文をメソッドに、データ構造をListにしてみよう、と思って最初は書いていました。
>>404-406,410,411
JavaDoc形式のコメント、クラス定義時の一般論や、DataOutput, DataInputのインタフェースやスキーマの利用方法、知りませんでした。
レビューを参考にして、色々調べ直してから出直します。コードをレビューして頂いて自分の無知がよくわかりました。ありがとうございます。
>>412
なにも参考にしないで、自分の欲しい機能を追加していきました。
あと、スレの流れ的に言いにくいのですが、>>408,>>419は、私ではありません。
このレスを書いていて発言する機会を失ってしまいました・・・。
427:デフォルトの名無しさん
13/06/30 03:31:57.59
> getAllRecords
仕様をはっきりさせるべきだろうね。今のコードでは確かに新しいレコードの
追加は出来ないけれども、個々のレコードの中の値の書き換えは出来る。
シャローコピーだから。それが嫌ならディープコピーを実装するしかない。
ディープコピーまでは不要、書き換え可能は承知で単にレコードの集合を参照
可能にしたいだけなのであればやはり返値は配列ではなくListにして、
return Collections.unmodifiableList(records);とでもするのが実装も簡単
だし全件コピーに比べてオーバーヘッドも少ない。
mainの中のループもfor(Object[] record: table.getAllRecords()){ ...と
でもした方が読みやすい。
428:デフォルトの名無しさん
13/06/30 03:36:18.89
なんだと～
429:デフォルトの名無しさん
13/06/30 06:11:06.80
>>427
ここまでくると異常者だな
430:420
13/06/30 07:39:46.72
>>421
getAttributeはテーブルクラスのメソッド名として不適切
100歩譲ってgetColumnAttributeなら可。
それにgetXxxx(index)はgetterと紛らわしい
431:デフォルトの名無しさん
13/06/30 08:49:45.89
getColumnAttribute
冗長な名前使っていてイライラせん？
getColAttr じゃいけん？
432:デフォルトの名無しさん
13/06/30 09:12:00.03
>>431
そういう省略は好まれない。人によって省略したりしかかったり、またどう省略するかがまちまちだと困る。
スペルアウトするのが原則。
433:デフォルトの名無しさん
13/06/30 09:31:36.34
>>432
誰が好まん？
434:デフォルトの名無しさん
13/06/30 09:45:57.18
>>433
コード読む人だろ。ColがColorなのかどうなのか定かじゃないだろ。
そんなとこでケチケチするちんけなやつのコードなんて見たくないってことだ。
435:デフォルトの名無しさん
13/06/30 09:47:19.17
コンストラクタでIO使うのが常識なのか？
init(入力ストリーム)ってメソッド作ったら初期化はコンストラクタでやれ
コンストラクタで読み込むようににしろって先生に怒られた
436:デフォルトの名無しさん
13/06/30 09:48:47.57
>>435
むしろ非常識でござろうな。IOExceptionをどう処理するつもりなんだ。
437:デフォルトの名無しさん
13/06/30 09:51:53.93
>>434
>>そんなとこでケチケチするちんけなやつのコードなんて見たくないってことだ。
さすがジャバラー（笑） 冗長な名前はムダなんだけどなぁ
バイトコードを解析した事ある？（笑）
438:デフォルトの名無しさん
13/06/30 10:05:05.10
>>432
>そういう省略は好まれない
ところでprintlnとconcatはどう思いますか？
439:デフォルトの名無しさん
13/06/30 10:13:11.98
>>435
>init(入力ストリーム)ってメソッド作ったら
コンストラクターが終わるとオブジェクトは構築されたと見なされる。
initを呼び出す前の状態が、クラス名の概念を表すオブジェクトとして適切かどうかによる。
>>436
コンストラクターでIOExceptionが出ると困るとか
どれだけジャバドカタは低脳なんだ。
440:デフォルトの名無しさん
13/06/30 10:35:01.08
>>439
>>initを呼び出す前の状態が、クラス名の概念を表すオブジェクトとして適切かどうかによる
どういう意味？
441:デフォルトの名無しさん
13/06/30 10:46:01.05
例外処理を当たり前に使うような手合いにはIO例外は外で受ければいいので気にならないんだろう
C言語の感覚が強い人はエラーは戻り値で判断するようにしたくなる
例外は文脈が吹っ飛ぶのであまり論理的でないしな
コンストラクタ内例外はnewの失敗としては検出できないのでそりゃ躊躇したくもなるだろう
442:デフォルトの名無しさん
13/06/30 10:55:32.68
>>438
組み込みメソッド名の中には、そういう歴史的な理由経緯の省略がある場合があるが、それはそういうものだと
理解するしかない。
そういうメソッド名を自分が作るクラスに使うのはOKだと思うが、複合名詞を自分のセンスで省略するのは
好まれない。特に、Javaの世界では、スペルアウトするのが好まれる。なぜそうなのかは知らないが、
Javaのネーミングの規範として、スペルアウトしろと言われるのを良く見かける。
443:440
13/06/30 10:59:52.32
>>441
例えば編集可能な文字列クラス(OreString)を自作したとする。
new直後は中身のデータも文字列の長さも未定義で、
initして初めて長さ0の文字列になるとする。
initする前は「文字列」の概念として不完全な存在だから
OreStringというオブジェクトは成り立っておらず、
この設計はおかしい。
この場合、OreStringContextとかOreStringDataとか
いうクラス名にするか、
コンストラクターでOreStringを適切な初期状態にする。
444:デフォルトの名無しさん
13/06/30 11:00:32.03
Javaは常にTAB一段分のハンデがあるから長い名前は厳しいな
445:デフォルトの名無しさん
13/06/30 11:02:43.78
>例外は文脈が吹っ飛ぶのであまり論理的でない
ジャバドカタは本当に頭が悪いな。
446:デフォルトの名無しさん
13/06/30 11:06:29.48
ここで>>445に論理的な例外を説明する義務が発生しました
・逃げる
・説明する
・SAVE
447:デフォルトの名無しさん
13/06/30 11:08:53.55
・ギムアップする
448:デフォルトの名無しさん
13/06/30 11:25:27.19
>>446
例外は「やりたいことが最後まできちんとできた」か
「やるべきことが全うできなかった」の二つしかない。
後者はcatchハンドラでまとめてエラー処理する。
極めて論理的じゃないか。
449:デフォルトの名無しさん
13/06/30 11:33:48.08
スペルアウトってなに？
スキルアウトの親戚？
450:デフォルトの名無しさん
13/06/30 11:39:39.18
コンストラクタで例外はともかくIOは気持ち悪い
インスタンスの構築とデータの読み込みは論理的に別の処理だからコードの上でも分けて欲しい
451:デフォルトの名無しさん
13/06/30 11:42:50.37
>インスタンスの構築とデータの読み込みは論理的に別の処理
それはクラスを「処理をするためのデータの集合」
としかとらえられない老害の発想だよ
>449
精液を放出することです
452:デフォルトの名無しさん
13/06/30 11:54:24.81
>>448
try-catchで囲まれた処理が
( A, B, C, ......, J )
と構成されている
やりたいことが最後まできちんとできたなら、全てのA-Jは成功している
やるべきことが全うできなかった場合を
NOT( A, B, C, ......, J )
とすると、君ならA-Jのどれが問題となる処理なのかをどう決定するか
そしてそれをcatchに書くことに気持ち悪さはないのか
途中でやめ！で済まされるほど簡単な処理で構成されてるとは限らないんだよ
453:デフォルトの名無しさん
13/06/30 12:03:53.36
>>452
>A-Jのどれが問題となる処理なのかをどう決定するか
別のエラー処理をしたいなら
A-Jごとにtry-catchすべき
454:デフォルトの名無しさん
13/06/30 12:15:13.20
try-with-resource使ってライーしてれば
あんま場合分けはいらないけどね。
tryだけ書いてcatchは書かないとかよくやる。
455:デフォルトの名無しさん
13/06/30 12:49:01.53
話が良く見えないが、コンストラクタの引数にストリームを渡すのじゃ駄目なのか？
456:デフォルトの名無しさん
13/06/30 12:55:52.91
>>445
ドカタは例外を理解できないのでだめ。
↓ こんな感じ
X x = new X();
try {
x.init(sutoriimu);
} catch (Exception ex) {//catchしないとコンパイルエラー
log.error(ex);
}
457:デフォルトの名無しさん
13/06/30 12:56:42.05
おっと>>455の誤りでした、すみません。
458:デフォルトの名無しさん
13/06/30 13:10:00.67
コンストラクタにストリームは継承した時に不便かな
ファイルふたつに分けなきゃならんのはめんどくさい
459:デフォルトの名無しさん
13/06/30 13:34:19.39
DI或いはそれに類する仕組みを使え
460:デフォルトの名無しさん
13/06/30 15:37:48.80
IOExceptionが出るような処理を
static { } イニシャライザ内に書いて欲しくないよなー
リソース読み込みなら、まあ譲歩してもいいんだけどさー。
461:デフォルトの名無しさん
13/06/30 18:29:51.29
>>437
インスタンス名、クラス名、メソッド名は簡略化して短くすることは推奨されていませんよ。
ましてや、インスタンス名はクラス名より短くする必要はないと公式に書いているよ。
もう少しよく使われているオープンソースであったりを読んだ方がいいと思います。
上げられたコードでもっというなれば、
getAllRecords()ではなくて
getRecordsAll()ですね～。
確かに細かいことかもしれないけれど、デザイパターン等しっかり学んでいる人から見ると
「インスタンス名、クラス名、メソッド名等の暗黙の了解・空気」等を感じ取れていないコードは稚拙に見えるのではないかな。
そしてそんなに難しく考えなくても、英語の強みをいかせるように書けばすんなり型にはめられますよ。
例えば、「getAllRecords()」は動詞と目的語が遠いですよね？
今回はたった三つの語の組み合わせなので大したこと無いように感じますが、後ろから修飾していないことに違和感を感じる人は多いと思いますよ。
日本語は頭でっかちに書いた方が美しいですが、英語だと・・・？
462:デフォルトの名無しさん
13/06/30 18:31:12.65
もちろん変数名等も。
連投失礼しました。
463:デフォルトの名無しさん
13/06/30 19:47:32.41
"get all records"と"get records all"をぐぐると・・・
464:デフォルトの名無しさん
13/06/30 19:48:40.12
ローカル変数までダラダラ長く書くやつは信用出来ない
経験的に数学出来ないタイプの人間が多い
465:461
13/06/30 19:52:11.80
URLﾘﾝｸ(www.oracle.com)
ここで入手できるJavaSE6のtutorialの、
[Language Basics]→[Variables]→[Naming]では次のように書かれています。
"When choosing a name for your variables, use full words instead of cryptic abbreviations."
続けて読み進めると、
[Classes and Objects]→[Classes]→[Declaring Member Variables]→[Variable Names]では、
"All variables, whether they are fields, local variables, or parameters, follow the same naming rules ...(略)"
と、さらに念押ししてわざわざ最初で触れた[Naming]の項まで飛べるようにまでなっています。
次に、[Defining Methods]→[Naming a Method]では
"By convention, method names should be a verb in lowercase or a multi-word name that begins with a verb in lowercase, followed by adjectives, nouns, etc."
となっており、先ほどの「getRecordsAll()」に「おや？」っと感じた人はいるかも。
で、この辺りが読むべき空気であると思います。（URLﾘﾝｸ(www.oracle.com)
あと、例えばA,B,Cのシーンクラスがあったとしたら、
SceneA
SceneB
SceneC
のようにA,B,Cを後ろに書くことでOS等がもつ名前順に並び替える機能を活かせます。
もっというと、それぞれがSceneクラスを継承したものであったら、名前順に並び替えるとsuperであるSceneクラスが一番上に来て最高です。
ソースコードが綺麗な人は当たり前のようにやっていたりいなかったり。。。
何はともあれ、ネーミングを短くしちゃう行為は公式で推奨されていませんよ。（しかも言語の基礎としてそれが書かれている・・。）
>>464 タイムリーなレスサンクス。勿論ローカル変数に関してもです。
466:デフォルトの名無しさん
13/06/30 19:52:47.27
ググったけど、get records allとか言ってる奴皆無なんだけど。
ググり方が悪いのか？
467:デフォルトの名無しさん
13/06/30 19:58:12.68
公式がいつも正しいとは限らない
特にjavaは各方面からボコボコに叩かれるぐらい洗練されてない言語
当然公式が間違えるのは前提として考えるべき
468:デフォルトの名無しさん
13/06/30 19:59:36.87
もう名前の話はどうでもいいので Iterable 実装してください
469:デフォルトの名無しさん
13/06/30 20:05:12.08
>>466
それは後ろにAll置くなら単数系のが合うからかと。証拠にググると皆無ではないよ。
それでも少ないのはプログラムの処理より普段使われている慣用句的に名付けてる人が多いから。
プログラムの意味的にはAllが後ろで単数系のほうがニュアンスとして正しいのでは？
470:デフォルトの名無しさん
13/06/30 20:17:26.52
そういや一時期JFrameのgetContentPane()メソッドに疑問もってた
なぜJPanelはlまでしっかり書いてるのにgetContentPane()はlを省略しちゃったのさ！って
後ほどpane自体で別の意味があることを知りなるほどと思った
471:デフォルトの名無しさん
13/06/30 20:25:02.10
>>470
そんなの考えるまでもなく一瞬で理解できるだろ…ｗ
472:デフォルトの名無しさん
13/06/30 20:44:30.18
冗長なシンボル使ってると 自分がバカになった気がする
473:デフォルトの名無しさん
13/06/30 21:03:48.12
>>471
英単語自信あったのにpaneなんて単語にこれまで出会わなかった
eclipseかbeans使ってりゃ冗長でも苦だとは感じないかな
オートコンプリートあるし
WIN32APIのような引数なら長い方が俺はましに感じる
474:デフォルトの名無しさん
13/06/30 21:06:13.45
英語に自信があると専門用語も詳しいとか
どれだけ自惚れが激しいんだ
475:デフォルトの名無しさん
13/06/30 21:16:29.85
自分の好みを人に押し付けてると 自分がバカになった気がする
476:デフォルトの名無しさん
13/06/30 21:25:13.97
スコープをちゃんと短くすれば変数の名前は頭文字や略称で十分
長い識別子かかなきゃわからないならそれは悪いコードになっている証拠
477:デフォルトの名無しさん
13/06/30 21:48:50.90
人はそれをコミュ障コードと呼ぶ
名をごまかし人目を避けることで何やってるかわからないようにしてごまかす
昨今のオープンソースやJavaの特性とは真逆
反抗したい精神・素直になれない精神はもはや中二病の延長ですまされるかなあ
478:デフォルトの名無しさん
13/06/30 22:09:39.61
カウンターはcountでなくcuntの4文字で
おながいします
479:デフォルトの名無しさん
13/06/30 22:11:50.85
>>478
なじぇ？
480:デフォルトの名無しさん
13/06/30 22:27:22.75
本当に下品
神聖なるJavaを汚すと罰があたるぞ！
481:デフォルトの名無しさん
13/06/30 22:29:33.91
JAVAが神聖とか冗談でもキモい
だが1996年頃はそんな奴が結構居た
482:デフォルトの名無しさん
13/06/30 22:45:55.23
Javaは、すみやかに普及した。その速度は、異常なくらいだった
483:デフォルトの名無しさん
13/06/30 23:21:17.27
>>418
CLASSPATH理解してなかったりするやついるくらいだから、まずはIDE使わない方が勉強にはなるんじゃないか。Javaのどこを勉強するかにもよるけど。
484:デフォルトの名無しさん
13/06/30 23:22:46.96
>>482
Java1.2くらいまでは、おもちゃ扱いじゃなかった?
485:デフォルトの名無しさん
13/06/30 23:36:57.83
てことはやはりJVMあたりから？
486:デフォルトの名無しさん
13/06/30 23:53:25.85
>>483
ドカタの過半数はclasspathを理解してないんだから
無問題
487:デフォルトの名無しさん
13/07/01 01:24:57.01
>>478
cntじゃないんだ
488:デフォルトの名無しさん
13/07/01 01:39:13.20
そこはJVMじゃなくてJITだろ
489:デフォルトの名無しさん
13/07/01 02:40:05.19
>>486
ドカタ目指すなら勉強は不要だろ。
490:デフォルトの名無しさん
13/07/01 02:51:13.36
単語省略するときは、まず母音から削るかな
491:デフォルトの名無しさん
13/07/01 03:53:04.59
省略するときは、適当な1文字にしてしまう
492:デフォルトの名無しさん
13/07/01 06:20:46.52
コントローラにSQLをコピペするだけの簡単な仕事です
493:デフォルトの名無しさん
13/07/01 12:25:53.06
1文字変数が許されるのはIteratorとcatch節までだよねー
494:デフォルトの名無しさん
13/07/01 13:49:42.09
>>493
そうだな、あとはv1,v2...と二文字にするべきだな。
495:デフォルトの名無しさん
13/07/01 17:41:52.72
コントローラーにSQLってのがまさにドカタの発想だな
struts使ったまではいいが、MVCの分離が
理解できなかった典型例
496:デフォルトの名無しさん
13/07/01 17:46:12.19
mp4をmp3に変換する方法ってありませんか？
ffmpegだと遅いのでこれ以外でお願いします
497:デフォルトの名無しさん
13/07/01 18:20:06.62
まず、エンコスレに逝きます
498:デフォルトの名無しさん
13/07/01 19:39:46.53
すみません文字列がsplitできるかできないかで判定するにはどうすればいいですか？
例えば
String line = "go kyoto";
String verb = line.split(" ")[0];
String place = line.split(" ")[1];
のような場合は問題ないと思いますが、lineがsplitできる保証がないときの判定法が知りたいです。
例えばもしline="go";だった場合、
ArrayIndexOutOfBoundsExceptionがでます。
(スペース" "は無いけれど[0]のsplitはできている？どちらにせよsplitできないと[1]を指定した時点で例外でますよね。)
499:デフォルトの名無しさん
13/07/01 19:40:31.44
>>497
エンコすれ行ってきます
500:デフォルトの名無しさん
13/07/01 19:54:55.93
>>498
splitが何を返すか見直してこい
501:デフォルトの名無しさん
13/07/01 19:57:45.50
>>498
String [ ] result = line.split(" ");
してから
result.lengthで判定だ。
502:デフォルトの名無しさん
13/07/01 20:34:33.81
コントローラーにガンガンなんでも入れちゃうのはむしろRailsでよくある症例だと思う。
ぶっちゃげRailsももはやドカタフレームワークだけど。
503:デフォルトの名無しさん
13/07/01 21:02:33.28
>>498
StringTokenizerを使う
StringTokenizer st = new StringTokenizer(line, " ");
if (st.countTokens()>=2) {//分割できる
String verb = st.nextToken();
String place = st.nextToken();
}
504:デフォルトの名無しさん
13/07/01 21:20:10.24
indexOfでええやん
いちいちオブジェクト作るなよ
505:デフォルトの名無しさん
13/07/01 21:32:56.21
Javaドカは作業ファイルを多用するので、その程度のコストは全く問題になりません
506:デフォルトの名無しさん
13/07/01 23:27:57.25
長大な文字列の極めて終端に近いところで最初の区切り文字が出てくる場合や最後まで区切り文字が出てこなかった場合
事前検索してからの分割はコスト的にどうなのだろうか
507:デフォルトの名無しさん
13/07/01 23:31:20.42
気にするな
パフォーマンスなんか土方には理解出来ない
cを使えるようになってからパフォーマンスとか気にすればおけ
508:デフォルトの名無しさん
13/07/02 00:29:09.24
土方仕事の実行時間はほぼ全てIOが占めるからね
細かいことはどうでもいいのよ
509:デフォルトの名無しさん
13/07/02 09:17:43.72
\x2022 Windows Internet Explorer
ブラウザを終了して続行しろと出て、全く先に進めません。
ブラウザは全部閉じています。
検索して調べたけど、「\x2022 Windows Internet Explorer」
について全然でてこなくてわかりません。
どうすればいいのですか？
環境はWIN7、IE10です。
510:509
13/07/02 09:21:19.56
失礼しました。
アップデートが上手くいかないのです。
511:509
13/07/02 11:23:19.97
再起動してから試しても、何度やっても途中「\x2022 Windows Internet Explorer 」
ブラウザを閉じろの繰返しだったのですが、先程すんなりと完了できました・・・。
設定など一切変更していないので、何が原因だったかわかりませんが
とりあえず完了できたので、お騒がせしてすみませんでした。
512:デフォルトの名無しさん
13/07/02 11:40:05.59
何のアップデートなのかも書けないとは
残念な奴だな
513:デフォルトの名無しさん
13/07/02 11:49:53.18
ごめんなさい、7 Update 21 から25へのアップデートでした。
514:デフォルトの名無しさん
13/07/02 12:14:40.58
windows 7のうぷだてとな
515:デフォルトの名無しさん
13/07/02 14:27:27.68
URLﾘﾝｸ(livedoor.blogimg.jp)
何が悪いのこれ？
516:デフォルトの名無しさん
13/07/02 14:45:51.37
>>515
Cジジイの頭が悪い
517:デフォルトの名無しさん
13/07/02 16:53:55.65
と見せかけた関数型言語マニアなのかもしれない
518:デフォルトの名無しさん
13/07/02 16:59:00.97
mp4とかの動画フォーマットからオーディオを抜き出せるライブラリってないですか？(mp4だけでもいいです)
ググってもフリーソフトしか見つかりません
519:デフォルトの名無しさん
13/07/02 17:01:46.98
便利なオープンソースやAPIを使えてwebに強いほうが良いに決まってるのに。
そして初めての言語がオブジェクト指向な方が得に決まっている
520:デフォルトの名無しさん
13/07/02 17:12:03.44
>>518
ffmpeg
521:デフォルトの名無しさん
13/07/02 19:41:53.19
>>520
ちょっと見てみたけど遅いです
直接吸出しできるのってないですか？
522:デフォルトの名無しさん
13/07/02 20:27:02.82
>>521
まず、直接吸い出せるツールを見つけてこい
523:デフォルトの名無しさん
13/07/02 20:28:07.51
ICカードを扱う無料ライブラリありますか？
524:デフォルトの名無しさん
13/07/02 20:29:36.65
>>523
まず正しく質問できるだけの知識をつけてこい
525:デフォルトの名無しさん
13/07/02 20:48:00.82
>>522
ffmpegで設定変えたら速くなりました
ありがとうございました
526:デフォルトの名無しさん
13/07/02 20:49:03.13
>>523
業務用で住民基本大腸カードを扱うなら
LASDECから入手が必用(C++)。
SuicaならたぶんC++向けAPIは提供されているだろう。
SmartOnなどの特定製品もSDKが販売されているだろう(たぶんc++)。
つまりお前のスキルでは無理。
それ以外のカードは無理ゲーに近いけど
意外とAndroidで探した方が行けるかも
527:デフォルトの名無しさん
13/07/02 20:55:36.79
ICカードは個人には仕様公開しないから働かないと使えないよ
528:デフォルトの名無しさん
13/07/02 21:05:10.74
>>527
何のICカードかにもよるが、個人で開発できるよ。
529:デフォルトの名無しさん
13/07/02 21:06:50.07
ICカードにJVM移植した「JavaCard」って、あれからどうなったの…
530:デフォルトの名無しさん
13/07/02 21:06:56.73
それはリバースエンジニアリングだろ
正式な仕様は非公開だよ
531:デフォルトの名無しさん
13/07/02 23:49:41.77
>>530
SDK買っても暗号化領域は読めないだろうし、そもそも書き込めない場合が多いだろう。
その意味では、法人でSDKを買っても仕様が全て公開されるわけではない。
逆に、個人でも見ることができる範囲でデータを読むことは出来る。
532:デフォルトの名無しさん
13/07/03 01:46:07.84
質問を読めない回答者が多いね
「ICカードを扱う無料ライブラリありますか？」
って質問なんだから、仕様が公開とか非公開とか関係ない
ライブラリがあるのかないのか答えろよ
533:デフォルトの名無しさん
13/07/03 06:05:15.69
>>532
ググれ馬鹿
534:デフォルトの名無しさん
13/07/03 08:11:16.76
今すぐ手軽にJavaでprintfで文字を表示させるレベルの簡単なプログラムを組みたいのですが
Windowsで無料で最短の開発環境を教えて下さい
535:デフォルトの名無しさん
13/07/03 08:15:43.27
eclipse
536:デフォルトの名無しさん
13/07/03 08:27:43.69
NetBeansのが手間無しだろ
537:デフォルトの名無しさん
13/07/03 09:01:31.78
何度もごめん
eclipseでC++でいう .cpp と main関数はどう作れば良い？
538:デフォルトの名無しさん
13/07/03 09:30:47.98
mainを作るチェックボックスをクリックする
539:デフォルトの名無しさん
13/07/03 10:06:28.46
test って名前のプロジェクトを作って
その中にパッケージを作って
その中にmainって名前のクラスを作るところまでは分かったけど
そこからが分からない
main関数を作っただけじゃ実行出来ないの？
選択にはメイン型が含まれていません
ってエラーが出る
540:デフォルトの名無しさん
13/07/03 10:08:11.70
main関数が入ったクラスを右クリックして実行ってすると
実行できるよ
541:デフォルトの名無しさん
13/07/03 15:48:35.13
ごめん
自己解決した
付き合わせてすまない
542:デフォルトの名無しさん
13/07/03 16:12:25.57
ムッキー
543:デフォルトの名無しさん
13/07/03 19:12:27.97
メンバの外部からの読み取りはOK、変更は禁止。といった、publicとprotectedの間くらいの設定をしたいです
大量のクラスメンバに対する大量のgetterメソッドを作るのが無駄な気がするので・・・
みなさんどのように対応していますか？
544:デフォルトの名無しさん
13/07/03 19:14:44.88
大量のgetterをIDEのプロパティ自動生成機能で作る
手打ちしなければ全く気にならない
545:デフォルトの名無しさん
13/07/03 19:26:45.85
なるほど、ありがとうございます。
546:デフォルトの名無しさん
13/07/03 19:28:22.05
アノテーションでgetterとかを自動生成するライブラリとかあった気がする
使ったこと無いけど
547:デフォルトの名無しさん
13/07/03 22:25:42.30
c++で言うとconst参照みたいなのはJavaには無いのですか？
548:デフォルトの名無しさん
13/07/03 22:26:59.50
無い
549:デフォルトの名無しさん
13/07/03 22:27:50.00
ない
イミュータブルなオブジェクトを使うとか
防御的コピーするとかしろ
550:デフォルトの名無しさん
13/07/04 06:23:06.78
Javaでデータベースを操作するアプリを作ってるのですが質問があります
毎日レコードが追加されるテーブルがあります
このテーブルを最新の半年分の情報とそれ以前の情報で別のテーブルに分けて管理する設計って悪い設計ですか？
新しい情報と古い情報は同じサーバーにあり格納するテーブルだけが違います
アクセスは新しい情報に集中します
551:デフォルトの名無しさん
13/07/04 06:47:00.49
>>550
あまり良い設計だとは思わないけど、実物見ないと何とも言えない。
アプリの形態はWeb？ DBMSは何？ 一日に何レコード追加されるの？ 1レコードあたり、およびトータルのデータ量は？
たぶん、適切なインデックスを張るとか、最近のデータだけmemcachedするとか、工夫の余地は色々あると思う。
あと、Javaよりもデータベースのスレで聞いた方かいいような。
552:デフォルトの名無しさん
13/07/04 06:53:07.50
DB板で聞くべき話だとは思うけどどのRDBMSを使っていてどんなスキーマでどんなクエリ
を投げるのか解らないと誰もアドバイス出来ないと思う。
ただし一般論としては、そういうテーブル分割を手作りすると古いレコードの移動とか
それに伴いアプリ側で生成するクエリを変更するとか、運用面で余計な手間やバグの
温床を抱えることが多い。RDBMSに詳しくない人が思いつきレベルで分けたのであれば
率直に言ってあまり関わりたくない、そういう設計。
まずはインデックスでどうにかならないか、あるいはシャーディングなどと呼ばれる
機能が使えないか調べることをお薦めする。
553:デフォルトの名無しさん
13/07/04 08:46:50.09
>>550
世の中にはOracleパーティショニングというものがあってだな
つまり性能上テーブルは分けるけど概念的には同一
というのは普通にあると言うことだ
554:デフォルトの名無しさん
13/07/04 09:40:16.30
>>550
RDB論的には間違ってる(ことが大半だと思う)。んだけどもじゃあ絶対そんな実装しないかというとそんなこともない。
実際そういうの作ったことあるし、よく見かけもするねー。
理由はパフォーマンスだったり運用上やら他のシステムとの兼ね合いやら。
要は状況次第ってことなんであまり回答になってないんだけど。
555:デフォルトの名無しさん
13/07/04 10:24:46.16
データ保存期間が数年で、保存期間MAXになるとレコード数が1000万レコードを超えるような
トランザクションデータの場合、年あるいは月によるパーティショニングか、
「直近のテーブル＋それ以前のアーカイブテーブル」という構造にすることは良くある。
556:デフォルトの名無しさん
13/07/04 10:43:24.31
abstractクラスのabstractメソッドの引数にenumを持たせたい場合
どういう設計をすればいいのでしょうか
イメージ的にはenumを定義しないとコンパイルエラーになるようにしたい
そしてenumの中身は継承先々で用意したいが、名は統一したい
557:デフォルトの名無しさん
13/07/04 15:29:12.90
abstractメソッドの引数にenumを与えたい、ただしどのenumクラスを使うかは
継承先に決めさせたい場合は普通にGenericsを使うかなぁ。
public abstract class AbstractSample<E extends Enum<E>> {
public abstract void sampleMethod(E item);
protected abstract Class<E> getEnumClass();
public void sampleMethod(String name){
sampleMethod(Enum.valueOf(getEnumClass(), name));
}
public class Sample extends AbstractSample<Sample.MyEnum>{
public enum MyEnum{enum1, enum2, enum3}
@Override protected Class<MyEnum> getEnumClass() {return MyEnum.class;}
@Override public void sampleMethod(MyEnum item) {...
getEnumClassは任意だけれども上記のようにString版のメソッドの実装も抽象
クラスで与えたいときなど便利。
> そしてenumの中身は継承先々で用意したいが、名は統一したい
「名は統一したい」というのがSample.MyEnumのように継承クラスでは必ず
MyEnumというenumクラスを内部クラスとして宣言する、ということを強制する
という意味なら多分無理。
558:デフォルトの名無しさん
13/07/04 17:37:45.07
>>557
abstractクラスのAクラスを継承したBクラス・Cクラス・・・内で
private enum Foo {
}
を定義していないとコンパイルエラーにしたい（可能なら）というのと、
「名は統一したい」というのは、Fooという名を統一して中身を各クラスで別に用意したいという意味です。
Bクラスでは
private enum Foo {
BAR, BAZ
}
Cクラスでは
private enum Foo {
QUX, QUUX, CORGE
}
というようにです。普通こういう場合、単なるメソッドならばsuperクラスのAクラスで
abstract protected void foo();
として、継承先で
@Override
private void foo() {
}
ですみますが、
abstract protected enum Foo;
なんていうのは許されませんよね？
となると、「Bクラス・Cクラス・・・でFooという名のenumを自分で定義する」というプログラムから離れた所にルールが生まれてしまいすこし嫌です（名がFooである保証がない？）。
可能ならば、このFooというenumをもたなくてはいけないことをsuperクラスで定義できないのかなと思って質問しました。
559:デフォルトの名無しさん
13/07/04 18:25:03.50
設計が変なんじゃないの？
enumは1つのファイルで作って使う値を全部列挙して
具象クラスでその値を使う時に無効な値をはじくようにしておけば？
public enum Foo {
BAR, BAZ, //Bクラスで有効
QUX, QUUX, CORGE, //Cクラスで有効
}
abstract class A {
abstract public boolean isValid(Foo item);
}
560:デフォルトの名無しさん
13/07/04 19:21:41.88
>>559
そうなんです。そしてそう書いてました。
だけど、Cクラスで使うときにBクラスでしか使わないBAR,BAZが可視なのを何とかならないかなとおもいました
561:デフォルトの名無しさん
13/07/04 19:26:20.46
>>550
twitterがそんな感じの設計をしてるね
適当にぐぐって見つけた記事
URLﾘﾝｸ(www.atmarkit.co.jp)
562:デフォルトの名無しさん
13/07/04 19:49:13.77
Twitterが必要とする設計が遙かに小さいスケールでも有効かというと単にオーバーキルで
手間暇増えるだけだったり。
インデックス設計の評価やDBMS組み込みのパーティショニングを検討するに一票。
563:デフォルトの名無しさん
13/07/04 21:36:28.52
年度別テーブルみたいなアプローチはインデックス貼るコストも安くなるからな
JPAが対応したら面白いがOracleさん的には困るか
564:デフォルトの名無しさん
13/07/04 21:58:41.98
>>550
それは水平分割って技法。DB設計ではアンチパターンに含まれる。
レプリケーションやインデックス、その他もろもろ全ての「正しい」解決法を試して
それでもパフォーマンスの問題が解決しなかった場合のみ使って良いというもの。
565:デフォルトの名無しさん
13/07/04 22:00:46.92
いつになったら板違いの話題をやめてくれるのかな
566:デフォルトの名無しさん
13/07/04 22:03:54.36
>>565
Javaの話題あんの？ないんだったら黙ってろよ。
567:デフォルトの名無しさん
13/07/04 22:05:00.37
>>564
何言ってるんだ。
パーティショニングこそ水平分割だろうが。
それに、レプリケーションなんか関係ないし。
568:デフォルトの名無しさん
13/07/04 22:15:51.10
半年分というのが、どういう機能要件なり性能要件に基づくものかがわからない限り、
どんなアドバイスも的はずれな可能性大なんだけど。
569:デフォルトの名無しさん
13/07/04 23:18:22.43
>>550 は悪い設計ですか？ と聞いてるだけだから
満場一致で悪い設計です と答えて終わりじゃないか
570:デフォルトの名無しさん
13/07/04 23:22:52.28
>>569
さすがコミュ障
571:デフォルトの名無しさん
13/07/05 00:02:14.86
半端な知識と仕込みで手を出しても無駄に苦労するだけの悪い設計。
572:デフォルトの名無しさん
13/07/05 02:49:37.88
JDBCは単なるSQLインタプリタなので、
デザパタ的にあまりおもしろい設計はできない。
他のDBライブラリはしらん
573:デフォルトの名無しさん
13/07/05 02:52:43.37
>>572
またてけと～なことを。
574:デフォルトの名無しさん
13/07/05 06:45:23.14
JDBCはSQLの中身には関知しませんよ
クエリとデータを右から左、左から右へ流すだけ
575:デフォルトの名無しさん
13/07/05 07:37:50.03
SQLインタプリタになっているJDBCやドライバの実装がどれほどあることやら。
576:デフォルトの名無しさん
13/07/05 08:34:20.80
「リレーショナルDBの世界がどうオブジェクト指向化されるんだろ」と
JDBC発表にワクテカしてたのは俺だけか。
SQL文を文字列で用意する必要があると聞いてがっかりしたず
「Table」に相当する抽象クラスがJDBCに出てこないってどういうことよ
577:デフォルトの名無しさん
13/07/05 12:23:44.61
実質スキーマレスになってしまうからじゃないか？
それリレーショナルなん？
578:デフォルトの名無しさん
13/07/05 14:22:08.65
JDBCにODBC相当物以上を期待していた人なんていないでしょ。
579:デフォルトの名無しさん
13/07/05 15:17:22.42
あのころはオブジェクト至高（ｷﾘｯじゃなくて
write once run everywhereで売ってたような
580:デフォルトの名無しさん
13/07/05 16:40:31.36
>>576
O/Rマッピングすればいいだけだろ
581:デフォルトの名無しさん
13/07/06 02:30:46.99
>>576
言ってること目茶苦茶すぎ
>>574が言ってるように、受け流すだけを担ってこそオブジェクト指向だ
おめぇさんはよぉ、銭湯いって風呂上がりのフルーツ牛乳が見当たらないからって
キレちゃうような輩なのか？
俺はきれるけどね
582:デフォルトの名無しさん
13/07/06 02:32:58.87
ただ、キレる相手は番台さんじゃねーってこった
583:デフォルトの名無しさん
13/07/06 02:34:00.46
javaee7にlinq入ったんだってね
コレクションだけらしいしViewのためだけにあるのだろうけど
584:デフォルトの名無しさん
13/07/06 02:43:58.43
ｗ
585:デフォルトの名無しさん
13/07/06 07:43:21.82
abstractクラスは便利ですね
public abstract class AbstractJInternalFrame extends JInternalFrame
{
private int x, y;
private int width, height;
private String title;
public AbstractWindow(int x, int y, int width, int height, String title, boolean resizable, boolean closable, boolean maximizable, boolean iconifiable)
{
super(title, resizable, closable, maximizable, iconifiable);
this.x = x;
this.y = y;
this.width = width;
this.height = height;
this.title = title;
}
public void resetPerspective()
{
System.out.println("Reset Perspective: " + title);
setBounds(x, y, width, height);
show();
}
// 以下フィールドのgetterのみ
}
みたいな設計が本当に便利に感じる。eclipseのReset Perspectiveの簡易版みたいな感じ。
iframes = new HashMap<String, AbstractJInternalFrame>(); あたりでまとめてたとすると、ActionListenr等で
for(Map.Entry<String, AbstractJInternalFrame> f : iframes.entrySet()) f.getValue().resetPerspective();
継承先でsetLocation(int, int)等で好き勝手できるけど初期値は断固としてsuperが守ってるみたいなイメージ。
586:デフォルトの名無しさん
13/07/06 07:47:24.55
あっそ
他の全員は知ってるから粉みかんは3行以内で頼む
587:デフォルトの名無しさん
13/07/06 07:55:33.83
あぁコンストラクタ名が間違ってるのは仕様でござます
588:デフォルトの名無しさん
13/07/06 08:19:53.00
抽象クラス使うやつは設計下手なザコ
589:デフォルトの名無しさん
13/07/06 08:40:10.98
抽象クラス使えない=クラスすら使えない（クラスはオブジェクト）
ってことに気づいているのだろうか
クラスも使えないとなると設計がうまい下手の段階までいけない件について…
590:デフォルトの名無しさん
13/07/06 08:46:01.06
意味不明
抽象クラスなんてテンプレート実装作るだけの道具にすぎない
多態はインターフェイスが基本で、抽象クラスは必須ではない
591:デフォルトの名無しさん
13/07/06 08:54:30.60
>多態はインターフェイスが基本で
インターフェースの無い言語はOOPではない
と言いかねないJAVAドカタの珍説には
いつも驚かされます
592:デフォルトの名無しさん
13/07/06 08:54:40.24
最近ちょくちょく抽象クラスがどうのこうのって話になるな
同じ奴が繰り返してるのか?
593:デフォルトの名無しさん
13/07/06 09:01:51.43
可能な限りインターフェースってのは全く同意だよ
そもそも公式がうたってますし
だけどいつも何でもかんでもインターフェースにしちゃうのは大反対
特に、extendsできなくなるのは場合によっては保守性が上がる
でもって、インターフェースが一番活きるのはこの時なんだよね～仕様的にも。
594:デフォルトの名無しさん
13/07/06 09:10:31.68
Java 8からはインターフェースも実装を持てるようになるから
抽象クラスと何も変わらなくなるよ
595:デフォルトの名無しさん
13/07/06 09:11:57.97
extendsの大部分は委譲で済んじゃうんだけどな。IDEの自動生成も使えるし。
596:デフォルトの名無しさん
13/07/06 09:12:23.36
>>594
抽象メソッドはprotectedにするもんだ
インターフェイスじゃできない
597:デフォルトの名無しさん
13/07/06 09:14:13.71
protected使うなんてレアケースだろ。一般論として語るのは……
598:デフォルトの名無しさん
13/07/06 09:19:35.46
まぁでも何もかわらなくなるってのは
先の「抽象クラス使うやつは…」のくだりと同じで極論すぎるよ
そしてprotectedがレアケースだとも思わないなぁ
それはニアリイコール抽象クラスをレアケースといっているようなもんだし…
599:デフォルトの名無しさん
13/07/06 09:22:09.09
Template MethodやFactory Methodはprotectedで十分なはずでしょ
MS系だとそれこそ仮想メソッドはほとんど全部protectedだったりするが
Javaってそのへん適当だよね
600:デフォルトの名無しさん
13/07/06 09:37:33.89
abstractクラスのfield活かした方が明らかに良い場合も無理してinterfaceなの？
それはちょっとどうなんだろう
interfaceだと子クラスに丸投げだよね？
601:デフォルトの名無しさん
13/07/06 10:02:17.81
ファクトリメソッドをprotectedはありえねーよ。
テンプレートは使う側ならprivateでなんも問題ないな。
仕様の方ならインターフェースで十分っつかpublicにしないと不便極まりないし。
602:デフォルトの名無しさん
13/07/06 10:11:56.80
>>601
>privateでなんも問題ない
privateはオーバーライドできません
>インターフェイスで十分
デザパタ知らないの? 移譲を使った設計と混同してるのでは?
603:デフォルトの名無しさん
13/07/06 10:21:35.57
ある機能を実装するとき、個々のクラスやら何やらで振る舞いが違う部分と
それらを呼び出す形で固定化できる部分に切り分けるのがテンプレートメソッドパターンなわけで。
固定化してる方はオーバーライドする必要が全く無いから、
外部からアクセスする必要がないならprivateで何の問題も無い。
604:デフォルトの名無しさん
13/07/06 10:23:20.22
Factory Methodがprotectedで十分とか
605:デフォルトの名無しさん
13/07/06 10:26:40.12
どう考えても両方使うだろ…
interfaceだけにしろ、protectedだけにしろ、privateだけにしろ…
何も考えていない証拠だ
606:デフォルトの名無しさん
13/07/06 12:45:38.25
抽象クラスはそのクラスの実装者からみたら窮屈に感じるが
protectedメソッドを実装するだけだと副作用が無くて安全にも感じる
ディスパッチ目的の抽象クラスだと実装がやたら手続き型でも気にならない
607:デフォルトの名無しさん
13/07/06 14:56:49.67
>抽象クラスはそのクラスの実装者からみたら窮屈
イミフ
>ディスパッチ目的の抽象クラス
イミフ
608:デフォルトの名無しさん
13/07/06 15:27:10.58
まずインターフェイスを用意して、それを実装する際に楽をする、してもらうために
抽象クラスも使うかな。両方使わないと不便。
APIに立ち現れるのはインターフェイスだけで実装クラスは基本隠す。
609:デフォルトの名無しさん
13/07/06 23:07:30.32
抽象クラスは何がダメかってスタンドアロンじゃない前提の癖に再利用性が悪いところだ
610:デフォルトの名無しさん
13/07/06 23:15:24.89
あるインタフェースのひな形だったりフレームワークへのエントリポイント
だったりするからな。ある方策に従わせるための抽象クラス
611:デフォルトの名無しさん
13/07/06 23:17:13.39
>再利用性が悪い
設計がＫＵＳＯなだけじゃね？
612:デフォルトの名無しさん
13/07/06 23:30:23.89
逆に他に実装可能な手段があるのにあえて抽象クラスを使うことが正解というケースがごく稀にしかない
613:デフォルトの名無しさん
13/07/06 23:31:20.92
ある抽象クラスのサブクラスが1個しかないならKUSO
分ける意味ねーもん
将来的に使いたいとしてもその将来っていつ来るの？って話
614:デフォルトの名無しさん
13/07/06 23:40:15.62
派生クラスに共通する役立つメソッドを抽象クラスで提供しよう
↑抽象でないクラスに分離してメンバに持たせるのが正解
615:デフォルトの名無しさん
13/07/07 04:42:24.53
>>613
例え一個でもわけた方がいい場合は間違いなくあるよ
だがabstractクラスはサブクラス沢山抱えたときにまとめて扱うのがいいよな
616:デフォルトの名無しさん
13/07/07 06:23:55.89
abstractクラスを継承したabstractクラス
みたいな構造のデザインパターンを経験しないと
メソッドにつけるfinalの有り難みが勉強できないんじゃないかなとは思う
617:デフォルトの名無しさん
13/07/07 06:27:19.94
出たー酷い失敗設計
618:デフォルトの名無しさん
13/07/07 10:02:43.44
将来どこを修正する可能性があるかを予想できないと抽象化は難しい
二度といじらないコードを抽象化するのは無意味だ
工期、予算の都合で今はしないけど次のサイクルでこれこれやる
ってくらい確実にわかっていなければ抽象化する必要はない
抽象化しなかった場所に修正が入るってなら設計上のミスだ
かむしろマネージャーの開発スケジュールミスだ
619:デフォルトの名無しさん
13/07/07 10:53:06.26
テストの為に抽象化することもあるんですが
620:デフォルトの名無しさん
13/07/07 16:09:58.78
>将来どこを修正する可能性があるかを予想できないと抽象化は難しい
んなこたーない。
現在の機能要件と拡張性要件に基づいて
設計するだけ。
621:デフォルトの名無しさん
13/07/07 16:35:50.06
要件なんてあてにならない
未来は神様にも予言できないんだよ
622:デフォルトの名無しさん
13/07/07 16:45:01.89
なんか良くわかんないんだけど、具象クラスしか作らないのかな
623:デフォルトの名無しさん
13/07/07 19:10:33.52
将来のためのインターフェースなんて、>>618くらいじゃない？
あとは、縦割り部署のインターフェースとか、、、
昔、DB部門が作ったインターフェースで、笑えないヤツがあったのを思い出した
テーブルの指定がひとつだけで、結合が全く出来ないという
624:デフォルトの名無しさん
13/07/07 19:55:56.48
ちょっと何言ってるかわかんないですねー
625:デフォルトの名無しさん
13/07/07 20:00:01.97
Javaやるとこうなる
シャブみたいなもんだよ
626:デフォルトの名無しさん
13/07/07 20:07:26.86
テーブルごとにクラス分けしててselect XXX from A,B（A,Bはテーブル）が考慮されてないってことか
通常のオブジェクト指向でもそうだが、ふたつのクラスの相互作用を表す方法に苦慮する
クラス（A＋B）を作るのは負けかなって思ってる
627:デフォルトの名無しさん
13/07/07 20:20:41.50
相互作用は簡単なものならイベントを使う
複雑ならプロトコルをクラスにする
通信対象の選択自体が複雑ならルーティングもクラスとして作る
面倒だが基本中の基本だろ
628:デフォルトの名無しさん
13/07/07 20:25:47.11
一部だけ人に書かせるときはAbstractが楽。特に土方に。
629:デフォルトの名無しさん
13/07/07 20:26:20.97
>>626
そこでLINQですよ
C#の劣化版猿真似は得意だろ？
630:デフォルトの名無しさん
13/07/07 20:56:30.08
>>628
最悪だろ
土方に正確なオーバライドは無理
631:デフォルトの名無しさん
13/07/07 20:57:31.73
>>629
無駄な通信が発生するのは同じだろ
632:デフォルトの名無しさん
13/07/08 00:15:20.02
>>629
まともな設計ならLINQはあくまでモデルの中で使うので同じことですよ
633:デフォルトの名無しさん
13/07/08 05:12:26.81
abstractクラス継承したabstractクラスはデコレータパタンとかでたまにみるね
634:デフォルトの名無しさん
13/07/08 05:41:47.78
Eclipseで、
実行（Ctrl + F11）のときは文字列を出力させず、デバッグ実行（F11）のときだけ文字列を出力したいです。
プログラムの中でデバッグ実行かどうか判別すればいいと思うのですが、
System.getProperties() で確認したところ、デバッグ実行のときだけセットされるプロパティは無さそうでした。
何かいい方法ありませんか？