★★Java質問･相談スレッド180★★ [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
プログラミング言語Javaに関する質問スレです。
JavaScript, Ajaxの質問は、ここでは受け付けていません。
Web製作管理 http://pc11.2ch.net/hp/
Webプログラミング http://pc11.2ch.net/php/
をご利用下さい。
よくある質問
・「コマンドまたはファイル名が違います」
「'javac' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。」
「Exception in thread "main" java.lang.NoClassDefFoundError: 」
(p)ttp://www.wikiroom.com/java/?path,classpath
・「\12288 は不正な文字です。」
文字リテラル以外で全角スペースは使えません。半角スペースに。
・その他の質問→「APIのjavadoc見ろ」
・String に == は使うな。equals() を使え。※
質問時の心得
・コンパイルエラーか実行時エラーか、エラーではないが意図しない動作なのかはっきりしろ。あとエラーメッセージちゃんと読め。
・前提条件としてOS、開発環境、バージョン、使用フレームワーク等を明記。
前スレ
★★Java質問･相談スレッド179★★
http://echo.2ch.net/test/read.cgi/tech/1476706523/ 当然、対象となっているフォルダに必要なjsファイルは設置しています javaとかjsp関連ではなくhtmlの範囲だと思うよ >>260
WEB-INF以下は外からアクセスできないのでむりぽ サーバー側でjavascriptを実行しようとする発想 スレチなので、jspでjQueryが使いたい場合はどうすればいいのか？御案内をお願いします。 WebProg板等見ても他に適当なスレが無いのでこちらで失礼します
【開発環境、IDE】Java SE 8、Eclipse Pleiades、Tomcat 8、MySQL 5.6.30
【Java歴】大学で2年
【質問事項】
Javaでプログラムを書いたことはあるものの、MVCとか意識するようなのは書いたことがありません
今回Servlet・JSPを初めて触っていて、MVCについて2つ質問があります
1.MVCに則る場合、例えばログイン処理を考えると、CがDAOにIDを問い合わせてpassを受け取り照合を行うのではなく、
照合はDAOに任せ、CはIDとpassをDAOに投げてbooleanで判定を受け取るだけにするのが良いのでしょうか
間違っている場合、「処理をCにやらせずMに分離する」簡単な実例を教えていただけるとありがたいです
2.http://at-grandpa.hatenablog.jp/entry/2013/11/01/072636
WebプログラミングにおいてはVとMCの間に壁があり、しかもユーザーが直接扱うのはVだけです
よって、この「本当の姿」は通常のアプリケーションの話で、
Webの場合はM←→C←→V←→ユーザーという考え方でよいのでしょうか >>277
以下、WebのMVCであることを前提
MVCはプレゼンテーション、ビジネスロジック、データアクセスの3層で言うと、プレゼンテーションとビジネスロジックの分離に関するパターン
DAOはデータアクセスの話なのでMVCとは関係ない
まず、コントローラがリクエストを受け付け、誰がこのリクエストを処理するか判断する
で、その処理担当のモデルに処理を受け渡す
モデルから処理結果が帰ってきたら、それを受けてコントローラがビューを呼び出す
2について
VとMCの間の壁とか考えなくていいよ
ユーザーからのリクエストがネットを経てようがそうでなかろうが、コントローラの役割は同じだから >>277
現実のドカタ開発においては、Mは単なるデータでありCにほぼ全ての処理を記述する
本来は口座クラス(M)の振込メソッドを呼ぶ ありがとうございます
>>278>>280
DAOがMだと思っていてその認識は違ったようですが、ログイン可否判定をMに任せるという考え自体は間違っていないのですね
JSP(と言うかブラウザの表示)＝V、Servlet＝Cという認識だったので、
ユーザーはVとしかやり取りをしない、また、Vはクライアント側でMCがサーバー側と思っていましたが、
ユーザーがブラウザを介して処理を要求するのは直接Cを扱っていると考えてよい、
また、どちら側とかいう区別は特に考えなくて良いのですね
言われてみれば、JSPも結局はServletですし、(やろうと思えば)ロジックを書くこともできるので、JSP⊃V（、C）という感じですかね
>>279
Java SEにTomcatとかを追加するとJava EEと呼ばれるのですね Viewはアプリケーションとその他の境界という考え方も >>281
Cがどこを指すかは定義がない。考え方によってはCが小さくなる。あなたのサーブレットをCとしてしまうと、MとVが小さくなりすぎて、Cの中がからんでいないかが気になる。 >>281
Java EEにJava SEが含まれる。Java EEは言語というよりはWebアプリの環境の総称。 よくよくみてみるとJSPがVとは言ってることが変すぎるな。 彼の解釈だと、VはWebブラウザ、Mはデータベース、Cはアプリケーションサーバとなってしまい、プログラムの話になってない。 >>287
落ち着いて読み返した方がいんじゃ・・・ そもそもMVCで考えること自体が現状に合っていないのでは？ >>282-289
入門として簡単な例で雰囲気を掴んでおきたかったので質問させていただきました
Mはデータと言うかデータ処理部ですよね
役割分担をさせる、という理念と概念はわかるのですが、
プログラムの実例が無いと結局どこからどこまでを分けるのかの理解は難しいですね
書籍を当たろうと思います
JSP＝V、Servlet＝Cという決まりはないということ、ログイン判定をCから分離する考えは間違ってないこと
がわかったのでよかったです
ありがとうございます いや、全然怒って真顔で冷静に書いてるだけとか、あるいはどのような反応になるかを学習しようとしているAIかも知れない。 >>260です
WEB-INFフォルダ以下はアクセス不可だと言うことは分かりました。
では、JSP&サーブレットでjsファイルを用いる時は、どこに配置するのがオーソドックスですか？ >>296
それってJSP/Servletの範疇じゃないし コンテキストルートの下にそれっぽいフォルダ作って置けばいい >>299
あなたが去るという選択肢も対等に存在しているよ 今日はデザインパターンの勉強したんだけど面白いね
仕事であんまり使う機会ないんだけど
いつかドヤ顔するために勉強してるw GoFはラムダが入った今となっては不要になったものも多いから気をつけないと逆に老害だぞ >>306
一生ねえわｗ
バブルソート極めた方がマシ >>307
まじすか
教えてちゃんですまんがこれだけは抑えておけ的なものがあれば教えてください >>309
Template MethodとIterator
プッシュ型の代表とプル型の代表としてこれだけはしっかり押さえとくべき
あとはだいたいそれらの変形や応用
間違ってもシングルトン厨にはなるなよ オブザーバの意義がわかりません
普通にあるインスタンスの状態が変わったら、一緒に状態変えたいインスタンスを並べてupdateすればいいんじゃないでしょうか？ >>312
基本的にはその通りで、呼び出し元が呼び出し先を知っている(依存している)場合はそれでいい。
でもそれだと都合が悪い場合もあって、例えば出来合いのボタンクラスはお前が勝手に作ったウィンドウクラスのことなど当然知らないから
ボタンクラスは自分がクリックされたとき何を呼び出していいかわからない。
そこでインターフェイスを介してメソッドを呼ぶことで、ボタンクラスがお前のウィンドウクラスを知らずともメソッドを呼び出せるという仕掛け。
これは見方を変えるとボタンクラスに呼び出してほしいメソッドを渡していると見做すこともできて、そういうやり方を一般に「移譲」と呼ぶ。
その移譲を使ってボタンクリックのようなイベントを実装したのがObserverであり、
移譲を使ってインスタンスの生成を一般化したのがAbstract Factoryだ。
GoFは個別のパターンの前に移譲の概念を確実に理解することを強くお勧めする。 メディエイター(仲介者・管制塔)
A - M - B
A, B は、互いに依存しない。
疎結合
Aを修正しても、Bを修正しなくても良い。
逆もしかり
オブザーバー・メディエイターは、モジュール同士を疎結合にする。
部品の疎結合が、最も重要 初歩的な質問ですみません
privateメンバをもったクラスを継承してサブクラスで更新したいのですが、
サブクラスからだと更新できません。
この場合、getsetを親に持たせるのがやはり一般的なのでしょうか？
メンバをprotectにして直接更新するのはあまり良くないのでしょうか >>315
変更すべきならprivateにしてる設計が間違えてる
privateが正しいなら変更しようとしてるのが間違えてる
こーしたらこーなるからでプログラムしたいなら制約を科すオブジェクト指向言語を使うのが間違えてる なるほど
では継承した子クラスから親の変数を変更しようとすること自体がおかしいということでしょうか
親に共通的に属性持たせて振る舞いだけ拡張していくのはよくあるやり方なのかと思っていましたがそうではないのですね どう作るかは正直どうでも良い
仕様が重要
目安としてそれぞれ別パッケージならsetter経由にしとけ >>315
getter, setter でやるのはそのクラスがその変数の変更タイミングを知る必要があるからだ。例えば書き換え直後に何か画面に描画するとかね。
変数の書き換えタイミングを知る必要がないならばその変数は public にして外部から直接書き換えられるようにしてしまえば良い。
外部から書き換える必要がないなら protected , 更に継承させたくないなら private。 >>318
そのクラスとメンバの意味合いによるだろ
お前にJavaはまだ早い >>321
いったい何言語で継承覚えたんだよ。
javaほど初心者向きの言語はないだろ… >>322
オブジェクト指向開発が早いってことだよ にしても実装から覚えるのかヤバイな
設計の教育しろ 目的がプログラムになってるヤツの多さは仕事においてもヤバい設計の教育はホント大事 昔のjava 1.5ぐらいで書かれたプログラムをNeon3でコンパイル通したいんだが、
javax.xml.ws とorg.apache.xmlrpcで検証が必要で、
それぞれ
「制約がありません。インポートパッケージjavax.xml.bindなんたらとか
エラーメッセージが出て、失敗してる。
コンソールで赤文字は
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [bundleresource://1080.fwk14070205:1/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [bundleresource://1080.fwk14070205:2/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
と出てる。
パスかクラスか足り無そうなんだが、教えてください。 >>326
なんでそのエラー見て「パスかクラスが足りなさそう」って考えに至るんだか
SLF4Jで使うロギングライブラリ実装がクラスパスに重複してんだよ >327 すいません。浅はかでした。ありがとうございました。 スポンジの生地を生クリームでデコレートするか、チョコクリームでデコレートするかみたいなもんだよ。
実装的には、連想配列のプロパティにでも、生クリーム、イチゴ、板チョコみたいに持たす感じか？
インタフェースを加えていくいう実装もあるけど。 ↑
ひっでえサンプル
世の中にこんな実装するやついんのかよ ま、デコレータは付加する部分を変えたクラスを作りやすくするパターンだからこんなもんでは？
たた、あまり必要ないような感じはするなあ。
付加する部分をパラメータで持たせてそれに応じて振る舞いを変えるようにするのがよくある作り方ではないか？
そうすると実行時に変更可能なようにも作れるしな。newした後で変えさせたくないならStringクラスみたいに変えられないように作ってしまえばいい。 以前VMの勉強してたときにJVMを作ったことがあります。簡単なやつで全機能を作ったら訳じゃないですが。ガーベッジコレクタの実装を検討してて、今の公式のJVMの実装に疑問を持ちました。
ガーベッジコレクタは、定期的にインスタンスの参照カウントが0のものを掃除していく作りになってると思います。定期的にではなく、即時に最後の参照がなくなった時点で解放すればいいんじゃないの？っ思いました。
ガーベッジコレクタの解放のたいみんぐが分からなくてfull GCが急に動いてシステムが不安定になったとかよく聞く話なんですが、今のハードなら都度解放でも問題ないくらい性能出せると思うんです。
何か問題あるんですね？ 実際は、DecoratorとChain of Responsibilityはセットで使われることが多いような気がする。
どっちも委譲の典型的な使い方でしかない。 >>336
とりあえずOracle JVMのParallel GCについて話をすると、いちいち個々のオブジェクトの参照数カウントなんてやってない
New領域がいっぱいになったタイミングで初めてその時点の参照有無をチェックしてまとめてGCしてる
また、そのチェックするタイミングと実際に削除するタイミングで全スレッドを停止しなくちゃならん(Stop The World)
個々のオブジェクトに参照カウントをもたせて管理するような実装もできるだろうけど、
1つのオブジェクトのGCのたびに全スレッド止めてたらJVMの性能が落ちそうだし、
増える方はともかく参照切れを正しく全部拾えると思えないな 参照切れを正しく拾えないって、どんな時にそうなるんだ？
確か参照カウント使って参照されなくなったらメモリ解放する方式は Delphi でやられていたと思うが、特に問題なくできてたと思うぞ。
(これの場合はコンパイラがバグってなければ大丈夫だよな？メモリ破壊するようなのを自分で書いてしまった場合は別かも知れんが)。 シングルスレッドだけなら参照カウントは比較的楽にできるかもしれんが
マルチスレッドの場合は参照カウントの読み書きは結構面倒くさい事になる。 >>339
あーごめんよ、自分が出来る気がしないだけ
変数がスコープを抜けた時に消すのはできそうなんだけど、null代入で参照切れるのをどうやって検出するのかなーと
JVMがやってる、とある時点のルートオブジェクトを起点として、参照を辿れないやつを参照切れとしてGCってのはわかりやすく感じる >>341
> null代入で参照切れるのをどうやって検出するのかなーと
代入直前に参照先の参照カウントをひとつ減らす（で0になったら解放する）だけ
ちなみにnullならなにもしなくていいけど他のオブジェクトへのポインタが代入されたらそのオブジェクトの参照カウントをひとつ増やしておく処理も必要
なのでそこそこオーバーヘッドがある
とりあえずWikipediaでも読んでおくれ
https://ja.m.wikipedia.org/wiki/%E5%8F%82%E7%85%A7%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88 ありがとうございます。
参照切れのことを書いてくれてる人が多いですが、即時にでも後でGCが回収する場合でも、(被)参照カウントを減らすのは関数が終わっときか、例外が出たとき、代入したとき、など同じになるはずで、解放するタイミングが違うだけだと思うんですよね。
参照がなくなる契機となるニーモニックは沢山なかったとおもう。
(被)参照カウントを持たずに、GCが毎回全インスタンスがどのインスタンスを参照してるか見るってのは非効率な気がする。
オブジェクトの型を見てメンバー毎に参照先のリストを作る必要があるので。 >>345
おー、ありがとうございます！疑問にに思ってたことそのものが書いてました。 質問です
classを２つつくり、メインの方に身長、体重のデータを置いて、サブの方にbmi計算式(体重/(身長*身長))を置き、メインの方で結果を表示させるにはどうすればいいのでしょうか？ まずは入門書を一冊終えてきたほうが早いよ
そのレベルじゃ教えようにも言葉が通じない >>347
public abstract class Main {
public static void main(String[] args) {
Main main = new Sub();
main.height = 1.70;
main.weight = 70.0;
System.out.printf("%.2f%n", main.calc());
}
double weight;
double height;
abstract double calc();
}
class Sub extends Main {
@Override
double calc() {
return (double) weight / (height * height);
}
} >>348 確かにまだ全然わからなくて苦戦してるので入門書買ってみます
>>349 実行しつつ、わからないところは調べてみます
ありがとうございました！ Java 7環境(ラムダもストリームもない)でコレクションの操作を快適に行うにはどうすればいいですか？
例えばオブジェクトのコレクションからプロパティのコレクションを作るといったような操作のたびに似たようなループ構造を持ったメソッドを書いていますがノイローゼになりそうです 仕事なら諦めて猿のようにループを垂れ流せばいい
どうせ労働時間で給料貰ってるんだろ?
当然そのループ生産作業も見積工数のうちなんだから、お前は堂々と工数をドブに捨てていればよい >>353
お前ループ書くのにどんだけ時間かかんのよw ランタイムが7でないといけないだけならKotlinを使う手もある 似たような作業が続いていると感じた時はツールを作成する機会。
今後も延々とループを書き続ける予感がするなら、
ループ構造をもったメソッドを自動生成するものを作れ。
ツール作成の手間と延々手作業を繰り返す手間との比較結果次第で。 ソース自動生成は最後の手段であり極力避けるべき
自動生成されたコードは次第に独り歩きを始め、あっという間にメンテ不能な巨大なクソの山の出来上がり たしかに節操なしに無計画にやるのは駄目だね。
まあノイローゼになるような作業のアウトプット自体がクソのような気もするが。
自身の精神のメンテも忘れず仕事がんばれ>352 ■ このスレッドは過去ログ倉庫に格納されています
