- 1 名前：デフォルトの名無しさん mailto:sage [2013/06/09(日) 20:27:10.93 ]
- プログラミング言語Javaに関する質問スレです。
JavaScript, Ajaxの質問は、ここでは受け付けていません。
Web製作管理 pc11.2ch.net/hp/
Webプログラミング pc11.2ch.net/php/
をご利用下さい。
よくある質問
・「コマンドまたはファイル名が違います」
「'javac' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。」
「Exception in thread "main" java.lang.NoClassDefFoundError: 」
(p)ttp://www.wikiroom.com/java/?path,classpath
・String に == は使うな。equals() を使え。
・「\12288 は不正な文字です。」
文字リテラル以外で全角スペースは使えません。半角スペースに。
・その他の質問→「APIのjavadoc見ろ」
前スレッド
★★Java質問･相談スレッド161★★
toro.2ch.net/test/read.cgi/tech/1364006637/
- 552 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 06:53:07.50 ]
- DB板で聞くべき話だとは思うけどどのRDBMSを使っていてどんなスキーマでどんなクエリ
を投げるのか解らないと誰もアドバイス出来ないと思う。
ただし一般論としては、そういうテーブル分割を手作りすると古いレコードの移動とか
それに伴いアプリ側で生成するクエリを変更するとか、運用面で余計な手間やバグの
温床を抱えることが多い。RDBMSに詳しくない人が思いつきレベルで分けたのであれば
率直に言ってあまり関わりたくない、そういう設計。
まずはインデックスでどうにかならないか、あるいはシャーディングなどと呼ばれる
機能が使えないか調べることをお薦めする。
- 553 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 08:46:50.09 ]
- >>550
世の中にはOracleパーティショニングというものがあってだな
つまり性能上テーブルは分けるけど概念的には同一
というのは普通にあると言うことだ
- 554 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 09:40:16.30 ]
- >>550
RDB論的には間違ってる(ことが大半だと思う)。んだけどもじゃあ絶対そんな実装しないかというとそんなこともない。
実際そういうの作ったことあるし、よく見かけもするねー。
理由はパフォーマンスだったり運用上やら他のシステムとの兼ね合いやら。
要は状況次第ってことなんであまり回答になってないんだけど。
- 555 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 10:24:46.16 ]
- データ保存期間が数年で、保存期間MAXになるとレコード数が1000万レコードを超えるような
トランザクションデータの場合、年あるいは月によるパーティショニングか、
「直近のテーブル＋それ以前のアーカイブテーブル」という構造にすることは良くある。
- 556 名前：デフォルトの名無しさん [2013/07/04(木) 10:43:24.31 ]
- abstractクラスのabstractメソッドの引数にenumを持たせたい場合
どういう設計をすればいいのでしょうか
イメージ的にはenumを定義しないとコンパイルエラーになるようにしたい
そしてenumの中身は継承先々で用意したいが、名は統一したい
- 557 名前：デフォルトの名無しさん mailto:sage [2013/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 名前：デフォルトの名無しさん mailto:sage [2013/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 名前：デフォルトの名無しさん mailto:sage [2013/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 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 19:21:41.88 ]
- >>559
そうなんです。そしてそう書いてました。
だけど、Cクラスで使うときにBクラスでしか使わないBAR,BAZが可視なのを何とかならないかなとおもいました
- 561 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 19:26:20.46 ]
- >>550
twitterがそんな感じの設計をしてるね
適当にぐぐって見つけた記事
www.atmarkit.co.jp/news/201004/19/twitter.html
- 562 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 19:49:13.77 ]
- Twitterが必要とする設計が遙かに小さいスケールでも有効かというと単にオーバーキルで
手間暇増えるだけだったり。
インデックス設計の評価やDBMS組み込みのパーティショニングを検討するに一票。
- 563 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 21:36:28.52 ]
- 年度別テーブルみたいなアプローチはインデックス貼るコストも安くなるからな
JPAが対応したら面白いがOracleさん的には困るか
- 564 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 21:58:41.98 ]
- >>550
それは水平分割って技法。DB設計ではアンチパターンに含まれる。
レプリケーションやインデックス、その他もろもろ全ての「正しい」解決法を試して
それでもパフォーマンスの問題が解決しなかった場合のみ使って良いというもの。
- 565 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 22:00:46.92 ]
- いつになったら板違いの話題をやめてくれるのかな
- 566 名前：デフォルトの名無しさん [2013/07/04(木) 22:03:54.36 ]
- >>565
Javaの話題あんの？ないんだったら黙ってろよ。
- 567 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 22:05:00.37 ]
- >>564
何言ってるんだ。
パーティショニングこそ水平分割だろうが。
それに、レプリケーションなんか関係ないし。
- 568 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 22:15:51.10 ]
- 半年分というのが、どういう機能要件なり性能要件に基づくものかがわからない限り、
どんなアドバイスも的はずれな可能性大なんだけど。
- 569 名前：デフォルトの名無しさん mailto:sage [2013/07/04(木) 23:18:22.43 ]
- >>550 は悪い設計ですか？ と聞いてるだけだから
満場一致で悪い設計です と答えて終わりじゃないか
- 570 名前：デフォルトの名無しさん [2013/07/04(木) 23:22:52.28 ]
- >>569
さすがコミュ障
- 571 名前：デフォルトの名無しさん mailto:sage [2013/07/05(金) 00:02:14.86 ]
- 半端な知識と仕込みで手を出しても無駄に苦労するだけの悪い設計。
- 572 名前：デフォルトの名無しさん mailto:sage [2013/07/05(金) 02:49:37.88 ]
- JDBCは単なるSQLインタプリタなので、
デザパタ的にあまりおもしろい設計はできない。
他のDBライブラリはしらん
- 573 名前：デフォルトの名無しさん mailto:sage [2013/07/05(金) 02:52:43.37 ]
- >>572
またてけと〜なことを。
- 574 名前：デフォルトの名無しさん mailto:sage [2013/07/05(金) 06:45:23.14 ]
- JDBCはSQLの中身には関知しませんよ
クエリとデータを右から左、左から右へ流すだけ
- 575 名前：デフォルトの名無しさん mailto:sage [2013/07/05(金) 07:37:50.03 ]
- SQLインタプリタになっているJDBCやドライバの実装がどれほどあることやら。
- 576 名前：デフォルトの名無しさん mailto:sage [2013/07/05(金) 08:34:20.80 ]
- 「リレーショナルDBの世界がどうオブジェクト指向化されるんだろ」と
JDBC発表にワクテカしてたのは俺だけか。
SQL文を文字列で用意する必要があると聞いてがっかりしたず
「Table」に相当する抽象クラスがJDBCに出てこないってどういうことよ
- 577 名前：デフォルトの名無しさん mailto:sage [2013/07/05(金) 12:23:44.61 ]
- 実質スキーマレスになってしまうからじゃないか？
それリレーショナルなん？
- 578 名前：デフォルトの名無しさん mailto:sage [2013/07/05(金) 14:22:08.65 ]
- JDBCにODBC相当物以上を期待していた人なんていないでしょ。
- 579 名前：デフォルトの名無しさん mailto:sage [2013/07/05(金) 15:17:22.42 ]
- あのころはオブジェクト至高（ｷﾘｯじゃなくて
write once run everywhereで売ってたような
- 580 名前：デフォルトの名無しさん mailto:sage [2013/07/05(金) 16:40:31.36 ]
- >>576
O/Rマッピングすればいいだけだろ
- 581 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 02:30:46.99 ]
- >>576
言ってること目茶苦茶すぎ
>>574が言ってるように、受け流すだけを担ってこそオブジェクト指向だ
おめぇさんはよぉ、銭湯いって風呂上がりのフルーツ牛乳が見当たらないからって
キレちゃうような輩なのか？
俺はきれるけどね
- 582 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 02:32:58.87 ]
- ただ、キレる相手は番台さんじゃねーってこった
- 583 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 02:34:00.46 ]
- javaee7にlinq入ったんだってね
コレクションだけらしいしViewのためだけにあるのだろうけど
- 584 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 02:43:58.43 ]
- ｗ
- 585 名前：デフォルトの名無しさん mailto:sage [2013/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 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 07:47:24.55 ]
- あっそ
他の全員は知ってるから粉みかんは3行以内で頼む
- 587 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 07:55:33.83 ]
- あぁコンストラクタ名が間違ってるのは仕様でござます
- 588 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 08:19:53.00 ]
- 抽象クラス使うやつは設計下手なザコ
- 589 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 08:40:10.98 ]
- 抽象クラス使えない=クラスすら使えない（クラスはオブジェクト）
ってことに気づいているのだろうか
クラスも使えないとなると設計がうまい下手の段階までいけない件について…
- 590 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 08:46:01.06 ]
- 意味不明
抽象クラスなんてテンプレート実装作るだけの道具にすぎない
多態はインターフェイスが基本で、抽象クラスは必須ではない
- 591 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 08:54:30.60 ]
- >多態はインターフェイスが基本で
インターフェースの無い言語はOOPではない
と言いかねないJAVAドカタの珍説には
いつも驚かされます
- 592 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 08:54:40.24 ]
- 最近ちょくちょく抽象クラスがどうのこうのって話になるな
同じ奴が繰り返してるのか?
- 593 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 09:01:51.43 ]
- 可能な限りインターフェースってのは全く同意だよ
そもそも公式がうたってますし
だけどいつも何でもかんでもインターフェースにしちゃうのは大反対
特に、extendsできなくなるのは場合によっては保守性が上がる
でもって、インターフェースが一番活きるのはこの時なんだよね〜仕様的にも。
- 594 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 09:10:31.68 ]
- Java 8からはインターフェースも実装を持てるようになるから
抽象クラスと何も変わらなくなるよ
- 595 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 09:11:57.97 ]
- extendsの大部分は委譲で済んじゃうんだけどな。IDEの自動生成も使えるし。
- 596 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 09:12:23.36 ]
- >>594
抽象メソッドはprotectedにするもんだ
インターフェイスじゃできない
- 597 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 09:14:13.71 ]
- protected使うなんてレアケースだろ。一般論として語るのは……
- 598 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 09:19:35.46 ]
- まぁでも何もかわらなくなるってのは
先の「抽象クラス使うやつは…」のくだりと同じで極論すぎるよ
そしてprotectedがレアケースだとも思わないなぁ
それはニアリイコール抽象クラスをレアケースといっているようなもんだし…
- 599 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 09:22:09.09 ]
- Template MethodやFactory Methodはprotectedで十分なはずでしょ
MS系だとそれこそ仮想メソッドはほとんど全部protectedだったりするが
Javaってそのへん適当だよね
- 600 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 09:37:33.89 ]
- abstractクラスのfield活かした方が明らかに良い場合も無理してinterfaceなの？
それはちょっとどうなんだろう
interfaceだと子クラスに丸投げだよね？
- 601 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 10:02:17.81 ]
- ファクトリメソッドをprotectedはありえねーよ。
テンプレートは使う側ならprivateでなんも問題ないな。
仕様の方ならインターフェースで十分っつかpublicにしないと不便極まりないし。
- 602 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 10:11:56.80 ]
- >>601
>privateでなんも問題ない
privateはオーバーライドできません
>インターフェイスで十分
デザパタ知らないの? 移譲を使った設計と混同してるのでは?
- 603 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 10:21:35.57 ]
- ある機能を実装するとき、個々のクラスやら何やらで振る舞いが違う部分と
それらを呼び出す形で固定化できる部分に切り分けるのがテンプレートメソッドパターンなわけで。
固定化してる方はオーバーライドする必要が全く無いから、
外部からアクセスする必要がないならprivateで何の問題も無い。
- 604 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 10:23:20.22 ]
- Factory Methodがprotectedで十分とか
- 605 名前：デフォルトの名無しさん [2013/07/06(土) 10:26:40.12 ]
- どう考えても両方使うだろ…
interfaceだけにしろ、protectedだけにしろ、privateだけにしろ…
何も考えていない証拠だ
- 606 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 12:45:38.25 ]
- 抽象クラスはそのクラスの実装者からみたら窮屈に感じるが
protectedメソッドを実装するだけだと副作用が無くて安全にも感じる
ディスパッチ目的の抽象クラスだと実装がやたら手続き型でも気にならない
- 607 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 14:56:49.67 ]
- >抽象クラスはそのクラスの実装者からみたら窮屈
イミフ
>ディスパッチ目的の抽象クラス
イミフ
- 608 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 15:27:10.58 ]
- まずインターフェイスを用意して、それを実装する際に楽をする、してもらうために
抽象クラスも使うかな。両方使わないと不便。
APIに立ち現れるのはインターフェイスだけで実装クラスは基本隠す。
- 609 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 23:07:30.32 ]
- 抽象クラスは何がダメかってスタンドアロンじゃない前提の癖に再利用性が悪いところだ
- 610 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 23:15:24.89 ]
- あるインタフェースのひな形だったりフレームワークへのエントリポイント
だったりするからな。ある方策に従わせるための抽象クラス
- 611 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 23:17:13.39 ]
- >再利用性が悪い
設計がＫＵＳＯなだけじゃね？
- 612 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 23:30:23.89 ]
- 逆に他に実装可能な手段があるのにあえて抽象クラスを使うことが正解というケースがごく稀にしかない
- 613 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 23:31:20.92 ]
- ある抽象クラスのサブクラスが1個しかないならKUSO
分ける意味ねーもん
将来的に使いたいとしてもその将来っていつ来るの？って話
- 614 名前：デフォルトの名無しさん mailto:sage [2013/07/06(土) 23:40:15.62 ]
- 派生クラスに共通する役立つメソッドを抽象クラスで提供しよう
↑抽象でないクラスに分離してメンバに持たせるのが正解
- 615 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 04:42:24.53 ]
- >>613
例え一個でもわけた方がいい場合は間違いなくあるよ
だがabstractクラスはサブクラス沢山抱えたときにまとめて扱うのがいいよな
- 616 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 06:23:55.89 ]
- abstractクラスを継承したabstractクラス
みたいな構造のデザインパターンを経験しないと
メソッドにつけるfinalの有り難みが勉強できないんじゃないかなとは思う
- 617 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 06:27:19.94 ]
- 出たー酷い失敗設計
- 618 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 10:02:43.44 ]
- 将来どこを修正する可能性があるかを予想できないと抽象化は難しい
二度といじらないコードを抽象化するのは無意味だ
工期、予算の都合で今はしないけど次のサイクルでこれこれやる
ってくらい確実にわかっていなければ抽象化する必要はない
抽象化しなかった場所に修正が入るってなら設計上のミスだ
かむしろマネージャーの開発スケジュールミスだ
- 619 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 10:53:06.26 ]
- テストの為に抽象化することもあるんですが
- 620 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 16:09:58.78 ]
- >将来どこを修正する可能性があるかを予想できないと抽象化は難しい
んなこたーない。
現在の機能要件と拡張性要件に基づいて
設計するだけ。
- 621 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 16:35:50.06 ]
- 要件なんてあてにならない
未来は神様にも予言できないんだよ
- 622 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 16:45:01.89 ]
- なんか良くわかんないんだけど、具象クラスしか作らないのかな
- 623 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 19:10:33.52 ]
- 将来のためのインターフェースなんて、>>618くらいじゃない？
あとは、縦割り部署のインターフェースとか、、、
昔、DB部門が作ったインターフェースで、笑えないヤツがあったのを思い出した
テーブルの指定がひとつだけで、結合が全く出来ないという
- 624 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 19:55:56.48 ]
- ちょっと何言ってるかわかんないですねー
- 625 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 20:00:01.97 ]
- Javaやるとこうなる
シャブみたいなもんだよ
- 626 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 20:07:26.86 ]
- テーブルごとにクラス分けしててselect XXX from A,B（A,Bはテーブル）が考慮されてないってことか
通常のオブジェクト指向でもそうだが、ふたつのクラスの相互作用を表す方法に苦慮する
クラス（A＋B）を作るのは負けかなって思ってる
- 627 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 20:20:41.50 ]
- 相互作用は簡単なものならイベントを使う
複雑ならプロトコルをクラスにする
通信対象の選択自体が複雑ならルーティングもクラスとして作る
面倒だが基本中の基本だろ
- 628 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 20:25:47.11 ]
- 一部だけ人に書かせるときはAbstractが楽。特に土方に。
- 629 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 20:26:20.97 ]
- >>626
そこでLINQですよ
C#の劣化版猿真似は得意だろ？
- 630 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 20:56:30.08 ]
- >>628
最悪だろ
土方に正確なオーバライドは無理
- 631 名前：デフォルトの名無しさん mailto:sage [2013/07/07(日) 20:57:31.73 ]
- >>629
無駄な通信が発生するのは同じだろ
- 632 名前：デフォルトの名無しさん mailto:sage [2013/07/08(月) 00:15:20.02 ]
- >>629
まともな設計ならLINQはあくまでモデルの中で使うので同じことですよ
- 633 名前：デフォルトの名無しさん mailto:sage [2013/07/08(月) 05:12:26.81 ]
- abstractクラス継承したabstractクラスはデコレータパタンとかでたまにみるね
- 634 名前：デフォルトの名無しさん [2013/07/08(月) 05:41:47.78 ]
- Eclipseで、
実行（Ctrl + F11）のときは文字列を出力させず、デバッグ実行（F11）のときだけ文字列を出力したいです。
プログラムの中でデバッグ実行かどうか判別すればいいと思うのですが、
System.getProperties() で確認したところ、デバッグ実行のときだけセットされるプロパティは無さそうでした。
何かいい方法ありませんか？
- 635 名前：デフォルトの名無しさん mailto:sage [2013/07/08(月) 06:35:26.12 ]
- リファクタリング機能をつかう
- 636 名前：デフォルトの名無しさん mailto:sage [2013/07/08(月) 12:02:52.75 ]
- デバッグ実行のときにプロパティをセットすればいい
- 637 名前：デフォルトの名無しさん mailto:sage [2013/07/08(月) 13:35:25.98 ]
- デバッグ実行だと動作遅くなるからベンチマークとってとか、間違ってそのままリリースして
遅い端末だとデバッグ情報が見れるw
- 638 名前：デフォルトの名無しさん mailto:sage [2013/07/08(月) 19:52:33.17 ]
- >>634
デバッグ実行時だけログ出力レベルをfineにすればいい
普通はlog4jだろうが俺はしらん
- 639 名前：634 [2013/07/08(月) 21:16:20.57 ]
- すみません、説明不足でした。
頻繁に実行とデバッグ実行を切り替えたいため、
ソースコードや設定ファイルを変更することなくやりたいのです。
- 640 名前：デフォルトの名無しさん mailto:sage [2013/07/08(月) 21:45:51.75 ]
- main メソッドを持つクラスを 2 つ作って起動し分けるとか
- 641 名前：デフォルトの名無しさん mailto:sage [2013/07/08(月) 21:46:51.82 ]
- だったらコマンドライン引数でいいだろ
- 642 名前：デフォルトの名無しさん mailto:sage [2013/07/08(月) 23:48:53.47 ]
- 最初のブレークポイント前後が100ms以上開いたら
「現在デバッグ中」フラグが建つということでどうだ？
- 643 名前：デフォルトの名無しさん mailto:sage [2013/07/09(火) 00:49:29.87 ]
- AspectJとかで実行時に文字列出力コードを織り込むとか
- 644 名前：デフォルトの名無しさん mailto:sage [2013/07/09(火) 08:44:37.39 ]
- >>630
なぜInterfaceやスクラッチだと正確にできるの? どれでも正確にできないなら比較の問題。ベターなもので満たせないなら、受け入れテストしてない方が悪い。自分がサボってるのを土方のせいにするなよな。
- 645 名前：デフォルトの名無しさん mailto:sage [2013/07/11(木) 21:50:36.58 ]
- visual studio+C#でできるデータベース操作のパクリはjava+eclipseには無いのですか？
テーブルアダプタやデータソースのことです
- 646 名前：デフォルトの名無しさん mailto:sage [2013/07/11(木) 22:10:37.58 ]
- visual studioがわからん人にはどういう機能かわからんからなぁ。
表形式でデータ見られたり、定義情報が見られたりするやつのこと？
- 647 名前：デフォルトの名無しさん mailto:sage [2013/07/11(木) 22:15:56.63 ]
- >>646
データベースへアクセスするためのクラスを自動で作ってくれる機能です
コードを一行も書かなくてもデータベースへのアクセスからフォームへのバインドまでしてくれるすごいやつです
- 648 名前：デフォルトの名無しさん mailto:sage [2013/07/11(木) 22:42:34.20 ]
- >>647
その程度なら、なければ自作しろ。
俺はそんなの全然ほしくないが。
- 649 名前：デフォルトの名無しさん mailto:sage [2013/07/12(金) 08:08:32.35 ]
- 山ほどあるから。
- 650 名前：デフォルトの名無しさん mailto:sage [2013/07/12(金) 09:51:16.96 ]
- JDBCが好き
- 651 名前：デフォルトの名無しさん mailto:sage [2013/07/12(金) 23:30:36.05 ]
- 最強のドカタ言語を舐めるなよ
- 652 名前：デフォルトの名無しさん mailto:sage [2013/07/12(金) 23:32:03.56 ]
- データベースからAccessみたいな環境を一式用意してくれるみたいな？
そいやJavaでクラサバとかしたことねーなぁ
|
 |
