[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 07/13 07:04 / Filesize : 160 KB / Number-of Response : 657
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

★★Java質問・相談スレッド162★★



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/

515 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 14:27:27.68 ]
livedoor.blogimg.jp/news23vip/imgs/1/d/1dba13cc.jpg
何が悪いのこれ?

516 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 14:45:51.37 ]
>>515
Cジジイの頭が悪い

517 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 16:53:55.65 ]
と見せかけた関数型言語マニアなのかもしれない

518 名前:デフォルトの名無しさん [2013/07/02(火) 16:59:00.97 ]
mp4とかの動画フォーマットからオーディオを抜き出せるライブラリってないですか?(mp4だけでもいいです)
ググってもフリーソフトしか見つかりません

519 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 17:01:46.98 ]
便利なオープンソースやAPIを使えてwebに強いほうが良いに決まってるのに。
そして初めての言語がオブジェクト指向な方が得に決まっている

520 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 17:12:03.44 ]
>>518
ffmpeg

521 名前:デフォルトの名無しさん [2013/07/02(火) 19:41:53.19 ]
>>520
ちょっと見てみたけど遅いです
直接吸出しできるのってないですか?

522 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 20:27:02.82 ]
>>521
まず、直接吸い出せるツールを見つけてこい

523 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 20:28:07.51 ]
ICカードを扱う無料ライブラリありますか?



524 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 20:29:36.65 ]
>>523
まず正しく質問できるだけの知識をつけてこい

525 名前:デフォルトの名無しさん [2013/07/02(火) 20:48:00.82 ]
>>522
ffmpegで設定変えたら速くなりました
ありがとうございました

526 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 20:49:03.13 ]
>>523
業務用で住民基本大腸カードを扱うなら
LASDECから入手が必用(C++)。
SuicaならたぶんC++向けAPIは提供されているだろう。
SmartOnなどの特定製品もSDKが販売されているだろう(たぶんc++)。
つまりお前のスキルでは無理。

それ以外のカードは無理ゲーに近いけど
意外とAndroidで探した方が行けるかも

527 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 20:55:36.79 ]
ICカードは個人には仕様公開しないから働かないと使えないよ

528 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 21:05:10.74 ]
>>527
何のICカードかにもよるが、個人で開発できるよ。

529 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 21:06:50.07 ]
ICカードにJVM移植した「JavaCard」って、あれからどうなったの…

530 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 21:06:56.73 ]
それはリバースエンジニアリングだろ
正式な仕様は非公開だよ

531 名前:デフォルトの名無しさん mailto:sage [2013/07/02(火) 23:49:41.77 ]
>>530
SDK買っても暗号化領域は読めないだろうし、そもそも書き込めない場合が多いだろう。
その意味では、法人でSDKを買っても仕様が全て公開されるわけではない。
逆に、個人でも見ることができる範囲でデータを読むことは出来る。

532 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 01:46:07.84 ]
質問を読めない回答者が多いね
「ICカードを扱う無料ライブラリありますか?」
って質問なんだから、仕様が公開とか非公開とか関係ない

ライブラリがあるのかないのか答えろよ

533 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 06:05:15.69 ]
>>532
ググれ馬鹿



534 名前:デフォルトの名無しさん [2013/07/03(水) 08:11:16.76 ]
今すぐ手軽にJavaでprintfで文字を表示させるレベルの簡単なプログラムを組みたいのですが
Windowsで無料で最短の開発環境を教えて下さい

535 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 08:15:43.27 ]
eclipse

536 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 08:27:43.69 ]
NetBeansのが手間無しだろ

537 名前:デフォルトの名無しさん [2013/07/03(水) 09:01:31.78 ]
何度もごめん
eclipseでC++でいう .cpp と main関数はどう作れば良い?

538 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 09:30:47.98 ]
mainを作るチェックボックスをクリックする

539 名前:デフォルトの名無しさん [2013/07/03(水) 10:06:28.46 ]
test って名前のプロジェクトを作って
その中にパッケージを作って
その中にmainって名前のクラスを作るところまでは分かったけど
そこからが分からない
main関数を作っただけじゃ実行出来ないの?
選択にはメイン型が含まれていません
ってエラーが出る

540 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 10:08:11.70 ]
main関数が入ったクラスを右クリックして実行ってすると
実行できるよ

541 名前:デフォルトの名無しさん [2013/07/03(水) 15:48:35.13 ]
ごめん
自己解決した
付き合わせてすまない

542 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 16:12:25.57 ]
ムッキー

543 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 19:12:27.97 ]
メンバの外部からの読み取りはOK、変更は禁止。といった、publicとprotectedの間くらいの設定をしたいです
大量のクラスメンバに対する大量のgetterメソッドを作るのが無駄な気がするので・・・
みなさんどのように対応していますか?



544 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 19:14:44.88 ]
大量のgetterをIDEのプロパティ自動生成機能で作る
手打ちしなければ全く気にならない

545 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 19:26:45.85 ]
なるほど、ありがとうございます。

546 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 19:28:22.05 ]
アノテーションでgetterとかを自動生成するライブラリとかあった気がする
使ったこと無いけど

547 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 22:25:42.30 ]
c++で言うとconst参照みたいなのはJavaには無いのですか?

548 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 22:26:59.50 ]
無い

549 名前:デフォルトの名無しさん mailto:sage [2013/07/03(水) 22:27:50.00 ]
ない
イミュータブルなオブジェクトを使うとか
防御的コピーするとかしろ

550 名前:デフォルトの名無しさん mailto:sage [2013/07/04(木) 06:23:06.78 ]
Javaでデータベースを操作するアプリを作ってるのですが質問があります
毎日レコードが追加されるテーブルがあります
このテーブルを最新の半年分の情報とそれ以前の情報で別のテーブルに分けて管理する設計って悪い設計ですか?
新しい情報と古い情報は同じサーバーにあり格納するテーブルだけが違います
アクセスは新しい情報に集中します

551 名前:デフォルトの名無しさん mailto:sage [2013/07/04(木) 06:47:00.49 ]
>>550
あまり良い設計だとは思わないけど、実物見ないと何とも言えない。
アプリの形態はWeb? DBMSは何? 一日に何レコード追加されるの? 1レコードあたり、およびトータルのデータ量は?
たぶん、適切なインデックスを張るとか、最近のデータだけmemcachedするとか、工夫の余地は色々あると思う。
あと、Javaよりもデータベースのスレで聞いた方かいいような。

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 ]
>再利用性が悪い
設計がKUSOなだけじゃね?

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クラスはサブクラス沢山抱えたときにまとめて扱うのがいいよな






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<160KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef