Java入門・初心者質問スレ Part.5©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
だいぶ亀レスですが、ご容赦ください・・。
>>97
やっぱそうですよね・・。どのWebページ見てもJSFは2からやったほうが良いようなことを書いてあります。
JSF1はくだけた解説書があるのですが、JSF2はあんまりないです(´・ω・`)…
Kindle本で評判悪いですが、あるのでやってみようと思います。KindleUnlimtedに加入すると0円らしいです・・・
お礼が遅くなりすみません。どうも体調が悪くて・・・。しかし、今時のWeb開発とは違うんですね・・。
私がやってたころは、Strutsしかなかったのに・・・。 保守作業するんでもない限り今からやるならspringのほうが良いだろ
むしろspringがあるからJava使うレベル >>105 Springってそんなにいいんですね。図書館にSpringの本がたくさんあったので
それやってみようと思います。J2EE関連の本はJSFばっか取り扱っているので、Springなんておまけみたいなものなんだろうと思っていました。それ、やってみます。
どうもありがとう。 プログラミング GROOVY、2011
Spring Framework 4 プログラミング入門、掌田津耶乃、2014
Spring Boot プログラミング入門、掌田津耶乃、2016 プログラミング速度を上げる方法を教えてください。
バリバリの初心者で、とにかくベタベタ上から書いています。
しかし、先を見据えてないので、書いて消して悩んで……で
時間だけが無駄に過ぎていきます(;;)
(料理の初心者が、あたふた料理している感じ)
何回なアルゴリズムをすぐに思いつく! ではなく……
普通のアルゴリズムの普通のソースコードを、
たんたんと書いていけるようにしたいのです。
(料理人が危なげなく、並列して料理している感じ)
みなさんは、どうやって開発、記述しているのでしょうか? >>108
行き当たりばったりに書かないで
全体から書いていくと良い
具体的にはUML(のクラス図とか)を書く
慣れたらいちいち書かなくてもいいけど
最初のうちは書いて全体の見方を覚える
そうすると料理で言ったら煮込んだり
時間のかかる調理をしながら
下ごしらえをするみたいなことができる
要するにムダがなくなる >>108
プログラミングで言うソースは
料理で言うレシピみたいなもんだからな
慣れだよ慣れ >>107
ありがとう。その2冊は図書館にあったので、見てみます。前から、ちょっとは見てみたいな…と思ってたやつです。
あと掌田津耶乃さんはけっこうSpringとかGroovyとか推してますよね(´・ω・`) JSFでググったときに出てきました。
一度読んでみます。ありがとう。ステマじゃないよw >>109
UMLは全図を勉強しましたが、もっぱらクラス図を見るだけですね。(〜_〜;)
クラス図以外は使っていないので、だんだんと記憶が……。
例えば、下記のような仕様のソースを109様が開発するときは、すらすらとクラス図にできるのでしょうか? もしコツがあるならご教授ください……!
稚拙な例ですいません(><)
「なんでも計算機」
・基本機能は加減剰余のみ。
・プラグイン形式で数学的計算機能を追加可能。
(開発者が追加していくパターン)
・プラグイン形式でユーザー独自の関数を追加可能。
・方法:テキストファイルに決まった形式でユーザーが関数を書き込み、
それを取り込み、機能を実現。
>>110
慣れ……ですか。(><)
110様の普段のコツは無いのでしょうか? >>112
>「なんでも計算機」
3D描画エンジンとかもそうだけど
そういう専門的なものを作る場合は
UMLとか一般的なOOP手法だけじゃなくて予備知識がいる
例というだけじゃなく本当にその仕様を実現したいなら
インタプリタとか言語処理系の知識が必要
「バリバリの初心者」向きの題材じゃない >>112
自分用にあったら便利そうな小さなツールから作っていく
次第に「あれとあれ組み合わせたらいいのできるかも?」みたいに思いつくから
段々規模を大きくしていく
でももし趣味とか好きだからじゃなく仕事で仕方なくとかなら思いつきにくいかも
後々土台の変更が必要になったりしてもいいなら
まず単純に加減乗除の式だけテキストから読み込んで実行できるようなのを作ったら
後は機能追加でいいから土台だけでもやってしまうとか
何桁まで扱うようにするのかとか多倍長整数まで扱うのかとかも要検討かな 面白いことに「数式を入力して計算するアプリを作る」よりは「色々な数式ボタンをつけた電卓を作る」ほうがずっと簡単なのだ
テキストパーサの知識はゆくゆくはあったほうがいいが、初心者がやるもんじゃねーな
んで、もし
プログラミング行為自体が遅い(1時間に打つ文字数が少ない、等)と思った場合:
・ 文字列やコレクションが持つメソッドの動作、高度な制御構造の使い方だけは絶対に記憶しておく
(書き方は覚えなくていい。「配列を○○する方法ってそういえばあったな」と気付ける程度でいい)
・ メジャーなデザインパターンを、これまた基本的な動作だけやって納得しておく(書けなくていい)
7割くらい機能ができた時点でかなり消して3割くらいから書き直すが動かない、みたいなことが頻発する場合:
・ gitや、gitや、あとgitのようなバージョン管理システムを利用する
(git類は「ここまでできたので保存しておく」「壊してしまったので保存時点まで戻す」「試しにコピーして改造する」がすぐできる。必須)
・ 上記に関し、メソッド単位で編集保存するという作り方を心掛ける(いきなりあちこち書き換えない)
メソッドAを使うメソッドBを作ったのだがそのまま動くと思ったメソッドAでエラーが出る、みたいな「このメソッドいきなり動かなくなった」が多発する
・ "ユニットテスト"を導入する。小難しい議論が大量にあるが当座「このメソッドはこの引数Aの時戻り値Bを返す、Cのときは実はD」という使い方でいい
UMLやクラス構成図を使っているのにぐちゃぐちゃになるという場合:
・いまのあなたに必要なのはもっと自由ならくがきである可能性が高い。方眼プロジェクトペーパーと書きやすいペンを用意しよう UMLは設計を整理したり人に伝えたりするもので
それ自体が分析設計を生み出すものではない
分析設計を生み出すのは開発手法
RPとかOMT >>108
大きな問題を小さな問題に段階的に繰り返し分解する
十分に粒度の小さな問題の解法は何度も必要になるのでメモするなりしてすぐ参照できるようにする
>>117が書いてるような文字列操作・コレクション操作・制御構造なんかはこのレベル
少しやってれば上のようなレベルは資料を見なくてもすぐ出来るようになるので
次はそれらの小さな問題を集めたもう少し粒度の大きい問題を解くパターンを認識して
それらをメモするなりしてすぐ参照できるようにする
これを繰り返していけば問題に対する解法をすぐに思いつけるようになる
それぞれの解法に対応したスニペットや汎用的な抽象化コードを用意しておけば
考える速度だけじゃなく書く速度も上がる
小中学校の算数・数学の問題を速く解くための勉強方法と基本的に同じ もしにひょっとしてIDEを使っていないのならIDEは使ったほうがいいよ
IDEなしにいまどきのJavaなんてタチの悪い修行だよ
書かないと覚えないだろなんてのはその「書くべきこと」が1行で済むような場合だけだ
IDEの使い方(正確には実行設定の仕方)とトラブル対処を覚えないといかんのでちょっとアレなのだけれど、そこをなんとか 「あるサブクラスのオブジェクト」から、
「そのスーパークラス」や「スーパーのスーパークラス」の
属性やメソッドを使用するのが苦手です。
サブクラス上から見えないからです。
エディタなどで上手く一覧する機能ありませんか?
importしたライブラリのメソッドや属性もどういう構成になっているか
がわかりません。 そもそも実装を継承しないのが良い
「継承より委譲」 >>123
継承を委譲に互換できるようにリファクタリング
する方法はありませんか? 普通に継承を委譲(集約)に
置きかえていけばいいんだよ >>113
なんとこの例は専門的なものだったんですね。
思いつきで考えた例なので申し訳ありませんでした。
>>114
設計がうまくなりたいです。
そうすれば眠る時間も増えそうです……。
(z_z)
>>115
小さなツールというのは再利用可能なクラスということでしょうか?
正直、私の作ったクラスはネストと専用処理だらけで再利用できないのです……。
>>116
怒られたというか、注意されました。
上司、先輩に確信を持ってコーディングしろと……。
担当レベルで「バグ0」にして提出と言われたので、今回のような
質問をしたら、「根性で学んでこい、とにかく動けばいい」と……。
根性で何を学んだらいいのか教えてもらえませんでした。
スレのみなさんの意見で、たぶん「設計」を学ぶと良いのかなと思いました。 >>117
丁寧に助かります。
GIT調べてみます。
ユニットテストはprintlnでログを確認してます。
私の開発手順は……
・口頭で「xxxなクラスを作ってくれ」と指示を受ける。
・クラス名を考えて、とりあえず必要そうなフィールドを書く。
・ここで手が止まる。(何か書かなきゃ、そうだ! アクセッサ!)
・全フィールドのアクセッサをかく。(焦る。とにかくメソッド書かなきゃ!)
・時価の商品価格を計算するとしたら、メソッド名(calcPrice)を書く。
・とりあえず分岐はするはず! そうだif文の枠だけ書こう!
・(省略)以下、確信なく恐怖でベタベタ書く……
・ifネスト、forネスト、switchネストな恐ろしいメソッドが1つできあがる。
(アクセッサ抜かすと、大抵はpublicメソッドが1〜2個しかない)
・printlnでログみてテスト。一応動くが、確信は無い。
・(そして大抵は)仕様変更、追加のお知らせが届き、デスマーチへ。
(合間に結果としてのエラーも当然でて、ブレークでトレースしてると
あっというまに1時間経ってます……)
>>118
RP、OMT、調べて参考書探してみます。
>>119
その粒度を小さくするという作業が「設計」ということでしょうか?
数学(簡単なもの)ならその分解作業が可能なのですが、
ことシステム設計になると、とっかかりが見つからないのです……。(><)
数学で言えば、計算式は解けるが、文章題から計算式が導けない感じです。
>>120
エクリプス使っています。
といっても、フォルダ管理と構文チェック、結果ログ見る程度です。 >・口頭で「xxxなクラスを作ってくれ」と指示を受ける
この時点で既に常識的な開発現場としてありえないんだが
ユニットテストまでやって仕様変更云々って言ってるってことは
もう詳細レベルまで落とし込んだ仕様があるのに口頭でやってとかありえんだろ
詳細設計書あるならどういう作りすればいいか壊滅的な馬鹿でもない限り誰でもわかるし
作り終わったらテスト仕様書作ってテストするから仕様変更やデスマーチも糞もねぇだろっていう
お前のところ色々おかしいかお前が意地悪されてるか敢えて何かを試されてるか何かだと思うわ ネストしまくるような複雑な条件の仕様を口頭で言うとかありえないから
とりあえず実際にどういう指示されたか書いてみ >>128
いやテストしてないと思う
"ユニットテスト"ってきちんと書かれてるのに「プログラムの動きをテストすること」だと思ってる(だからprintlnという頓珍漢な答が)
https://qiita.com/takehiro224/items/a5d4265c4a1b36b0919c
ともあれ最初の業務でやってるのならツール的なアドバイスは無駄かもしらんね 配列定数はイニシャライザーにおいてのみ使用可能です
これどういう意味ですか? >>131
それ自体はそのまんまの意味だが、配列リテラルを代入し損ねてるときに言われることが多い
その代入の書き方は本当に合ってる? arrじゃなく arr[ ] とかが必要なんじゃない?? >>127
>その粒度を小さくするという作業が「設計」ということでしょうか?
設計の一部だけど全部じゃない
一つの問題に対して解法は一つではないので
複数ある選択肢からどの解法の選択するかが設計の核
問題の分解方法は解法選択の一部
>数学で言えば、計算式は解けるが、文章題から計算式が導けない感じです。
これは問題を明確に定義できてないから
明確に定義されてない問題は解けない
「xxxなクラスを作ってくれ」と指示を受けたらまず以下3点を明確にする
1. なぜそのクラスが必要なのか? クラスの責務は何か?
2. そのクラスに必要なパブリックインターフェースは?
- 例外を含めた入力・出力の型(メソッドシグニチャ)
3. どういうテストをパスしたら十分なのか?
- 事前条件、事後条件、不変条件
3点とも指示を出した側に質問する必要がある(嫌がられてもしつこく)
特に3の何ができたら問題を解けたと言えるのかを明確にするのが一番大事
問題の定義と解法の選択、解法の選択の主要な方法として問題の分解がある
算数で考えればものすごく当たり前だよね >>126
設計を考える上で標準ライブラリを参考にするといい
たとえばどの言語でも日付なんかは標準になってる
そういう共通してて何度もおこなう処理を考えよう
たとえば価格の計算であちこちで何度も
税額を算出してるならメソッドにくくり出すとか
>>127
とりあえずクラス使ってるってだけで手続き的な
オブジェクト指向らしくないコードのようだね
なるべく深いネストは外していこう
メソッドに抽出してその組み合わせで処理する
そうして粒度を細かくすると
クラスやメソッドの数が増えて不安かもしれないが
重複が減るし読み書きしやすいから
その方が全体として作業量は減っていく 皆様、いろいろご丁寧にありがとうございます。
指示は先輩が手帳を見ながら口頭で伝えられるので、
それを急いでメモするという感じです。とにかく忙しそうです。
具体的な内容は業務内容に触れてしまうので控えさせてください。
とりあえず、下記のことをやってみようと思います。
・設計の本で良いのがないか本屋で探す。
・仕様詳細をもっと聞く。
・まずクラス図を書いて、責務の粒度を細かくする。
・再利用できるメソッドを作るよう心がける。
(といっても、どうやればいいのか……)
あとは、みなさんのレスを反芻していきます。
本当にありがとうございました。
最後の質問ですが、設計に関してのおすすめの書籍はありますか?
ぜひ、購入したいと思います。 >>135
>設計に関してのおすすめの書籍
まずJavaやOOP自体に慣れてないなら
『スッキリ Java』が一番やさしい
狭義の設計じゃないけど設計力の土台になるのが
『Javaで学ぶアルゴリズムとデータ構造』
本題の設計は難解な本が多いから
UMLの本とかデザインパターンの本とか個別のテーマで
やさしそうな本から読んでいくのがオススメ
メソッドの抽出とかは『リファクタリング』に
いろんな手法が載ってるから
ある程度JavaやOOに慣れたら読んでみよう >>127
アクセッサは、アノーテーションを付けるだけだろ
テスト駆動開発(TDD)でやる。
最初は関数で処理を作っていき、だんだん高度になってくると、クラスにする 書いてる内容見る限り、立ち位置的に設計云々とかクラス図とか
考えるレベル以前の問題で職場の奴はそういうのは求めてないように見える
言われて作ったクラスがどういう使われ方してるのかもよくわからんし
書いてる事から想像するに、勉強も兼ねた誰かの手伝いとして適当に使われてるだけだろ
いずれにしても作業指示の仕方が糞すぎるからそこは辞めた方がいいよ >>136
>『Javaで学ぶアルゴリズムとデータ構造』
あっ今検索したら同名の書籍があったけど
望洋の明解シリーズの奴ね
図解が多くて分かりやすいから >>135
> ・再利用できるメソッドを作るよう心がける。
1, これは再利用するだろうなってのをメソッド化
2, この処理は別の所でもやったなってのをメソッド化
3, 機能毎にメソッド化(分割や統合)できそうだなってのをメソッド化
他にもあるだろうけどこんな感じでいいよ 自宅で自分用の(自分で勉強するための)プログラムを書いて慣れるというのがいちばんだと思う
業務指令で範囲限定されたコードだけ書いててもまっっっったくメソッド感覚(?)は身につかないよ
だって「そんなことしなくても動く」もの、業務中にやる理由ないよね 口頭で伝えるのは後から改変するための常套手段
証拠は残さない なぜこのクラスが必要なのですかと訊くと
キレ気味にいいから黙ってやれと言われる
別にイヤとかやりたくないとかじゃないんだけど適当な仕様だと文脈背景わからないと間違いの元
他の奴が黙ってやっちゃうから味を占めたんだろうな
また無駄な後戻り工数が生まれて実装のせいにされる わかってないだけだって
人はわからないことを聞かれた時に不機嫌になるってのはわかるだろ >>142
そのせいなのかメールで聞くと返事が返ってこないやつはマジでイラつく
そういう奴は無責任の意気地なしとみなす >>135
>・再利用できるメソッドを作るよう心がける
間違ってもいないんだけど実際には
最初から再利用を目指すより
リファクタリングで重複した処理を
メソッドに切り出す方が簡単なんだけど
「動いた物をいじるな」という職場だと
まあそっちもそっちで難しいよな >>145
口頭で聞いた後に
先程の備忘です。
認識齟齬などあれば返信にて訂正願います。
とかなんとか理由付けてこっちからメール送ればいい
一手間かかるけどある程度身を守れる >>142
じゃあ録音しとけ。
または忘れやすいということにして詳細にメモをする。 >>136
書店で推薦書を購入し、
1「スッキリ」の2冊
2「Javaで学ぶアルゴリズムとデータ構造(明快シリーズ)」
の順番が良いかと思いましたので、
本日からスッキリを学んでいこうと思います。
ありがとうございました。
>>138
おっしゃる通り、重要業務は任されていないと思います。
今はとにかくスキルを上げたいと考えています。
>>140
たぶん再利用可能メソッドは標準ライブラリで提供されているような
ものだろうと思っています。
なんとかくくり出せるように考えてみます。
>>146
デザインパターンをマスターすると保守しやすいクラスや
メソッドになると知りました。
デザインパターンとリファクタリングも学んだほうが良いようですね。 今から「スッキリ」で勉強を始める、素人か。
そんな奴に、一々説明していたら、数年かかる
オブジェクト指向を知らない奴は、仕事でプログラミングしたら、いけないレベル
少なくとも、Java の本を10冊読んで、資格や数年以上の経験が必要 本10冊くらいはそりゃ読む必要あるけど
資格や経験年数はほとんど関係ないよ
本人の素質と努力次第 新卒?中途採用?
何歳か知らんけどプログラミングほとんどやったことないなら
普通研修みたいなの1か月ぐらいは与えられるもんだが今がそれなのか? その辺はその会社次第なんじゃないの? 教育やる余裕がない小さい会社とか
大きくてもその辺のこと分かってない会社とか色々あるだろうし。
ま、しかし、基本的にワザは教えて貰うよりは盗んだ方が良いだろうな。
自分で求めてこうだと分かったことなら忘れないが教えて貰ったことは忘れるから。
なんてことをこの前テレビで坊さんが言っているのを聞いてその通りだと思った。 Javaの「スッキリ」はRPGで言うと
「ひのきの棒」や「竹のやり」みたいな初期装備だが
丸腰よりはるかにマシ
「明解」でやっと「銅のつるぎ」
ファウラーの「リファクタリング」や
GOFのデザパタやエヴァンスのDDD本は
もっと高級な剣だが
レベルが足りないと装備できない ひのきの棒という役割を演じるゲームか
シュールだな >>154
そのスッキリは入門編(黄緑の方)のことですよね? >>156
そうだよ
でもスッキリ2冊読んで終わりとか
それほど甘くはないよ
スッキリは基本的に初心者向け オブジェクト指向はあまり良くないだろな。
GUIと相性が良かっただけで、その他一般的な問題とは親和性が低い。 オブジェクト指向が一番汎用的だと思う
DDDがOOメインなのもそこだし >>157
レスが遅くなってすいません。
そうですよね、ありがとうございます。
でも今の自分には実践編(緑の本)の中盤以降が結構難しいです…。 オブジェクト指向がマッチしないと言っているのは
設計を構造化とかどやっといて
オブジェクト指向プログラミング使えないと言ってる奴がよくいる
機能とか流れって出てきたら注意 オブジェクト指向がよくわかってないからマッチさせられないだけではないか? >>156
リストの頭だけを掻き集めてリスト化したような良書ではある メモリー使用量が個人利用の壁になっているんだろうな。 Javaの個人利用が難しいのは
安いレンサバで使えないのが大きいのでは 大抵PHP.良くてPython.ruby止まりかな 何故使えるようにならなかったのか考えないのがJavaユーザぽくていいよね。 スクリプト言語はその場で書き直しゃ動くからねぇ
JavaとかC#とかはビルド→デプロイまたは
ビルド→パッケージング→デプロイとか面倒
GAEはどこまでショートカットしてくれるのか知らん 俺って大体そこらへんの能無しより2倍ぐらい仕事早いほうなんだけど
金融系の内部管理システムで1画面にボタンが20個ぐらいあって
段階的に5回ぐらい認証する機能で鬼のように状態持ってるから
設計書の相関チェックも凄いことになってて当然こんなレベルの機能だと
設計書にも不備ありまくりで実装してく度に何十回も設計者と確認しないといけないレベルで
外部結合で持ってくる情報も鬼の用にあるからSQLも100行超えるわ
外部ファイルも取り込んだりするわでエビデンスのページ数も余裕で100ページ越えるレベルで
これが最初テスト完了まで2週間ぐらいの線表で
毎日残業して1か月かけて作ったらプロパーが後ろで「こんだけ時間かけられるとは思わなかったわ」とか
嫌味言ってくるのが典型的な能無し無能システム会社なんだよな そういう無理のあるものを断れない立場に居ること事態が既に能のある状態とは言えない 過疎ってるから暇つぶしに書いただけだ
プログラムやらず嫌いのプロパーしかいない無能会社の中でも大ハズレの部類
当たりはバグ調査が全然できないプロパーがいるところのバグ調査担当 JDK 8u151と8u152、2つ出てるけどどっちをインストールすればいいの? >>171
スクリプトでもバージョン管理してるから他で書いてやっぱりデプロイしてる
個人でも ストリームバッファについて質問です。どれがいいのでしょうか?
FileInputStream fis=new FileInputStream("file");
0.
InputStreamReader r=new InputStreamReader(fis);
1.
InputStreamReader r=new InputStreamReader(new BufferedInputStream(fis));
2.
BufferedReader r=new BufferedReader(new InputStreamReader(fis));
3.
BufferedReader r=new BufferedReader(new InputStreamReader(new BufferedReader(fis)));
そもそもバッファの効果もよくわかってません 訂正
3.
BufferedReader r=new BufferedReader(new InputStreamReader(new BufferedInputStream(fis))); BufferedReader br = Files.newBufferedReader(path,charset) >>180
バッファがあると一回の読み書きに時間が掛かる機器の場合に効率が良くなって速度が上がる可能性がある。
例えばHDD。一回の読み書きが遅いのでまとめて読んだり書いたりした方が速度は上がる。
ということでファイル入出力にはバッファがあった方が良い。 その手の質問には「1万回繰り返すと2倍くらい違う」と答えることにしてる 割合算でいいんじゃないの
つまり速い方に書き換えると「その部分だけが」2%くらい速い
そこの処理が0.03秒だった場合は処理速度が0.0294秒になって0.0006秒の改善になる
どっちかってと速度なんかじゃなくHDDとメモリ酷使するのを良しとするかどうかで動作決めていいよバッファ系は >>188
するよ
そこまで行ったならオブジェクト生成コストやGC負荷とアルゴリズム、加えて「コ ン パ イ ラ が 完 全 最 適 な オ ブ ジ ェ ク ト 構 成 に 置 き 換 え て く れ る」まで考えて、
結局は実際に計測して遅くなきゃいいや、人力脳内最適化は無意味でクソである、といういま一番トレンドな結論に至る
おめでとう >>184
接続されてるHDDやプログラムがどのぐらい細切れにデータを読み書きするかで変わる。
ま、なんだったら自分でバッファありとなし作って試してみな。だいたいはバッファありの方が速くなる筈。
速度差が出ないとか、むしろ遅くなる場合はバッファの大きさがそのプログラムでの一度の読み書き量に対して適切ではないとか接続されているHDDに対して適切ではないのかも知れない。
あるいは最初から適切だったためにバッファありにしても殆ど変わらないかかな。固定長の大きな電文を自分で作ってその単位で読み書きする場合はその電文の塊がバッファみたいなものなので変化がないかも知れない。 OSはほぼ確実にバファリンしてるのでHDDの読み書きではなく、システムを呼び出すオーバーヘッドで
変わるだけじゃないだろか。 BufferedReaderを使うとシステム呼び出し回数が減らせるのでスレッドの切り替え確率が
減るという説明のほうが納得がいくような気がスルスル。 OS・HDD は、バッファリングしてる
だから突然の電源断により、書き込まれない事があるため、
必ず正常にシステムを終了させること
普通OSは、5秒ごとに、HDDに書き込む
フラッシュメモリーには、書き込み回数の上限があるため、
SSD の書き込み回数が気になるなら、15秒ごとに書き込むように設定できる Javaの最大の欠点は100kbのデータを扱うプログラムにGBクラスのメモリーが必要になるような
効率の悪さ。 https://i.imgur.com/ex4qwLj.jpg
大学の課題なんだが、for文のi<5のあとにlengthをつけなくてもこの課題は解決できるのかを教えてくれ。 >>198
どういう場合にそうなんの?
普通なら大丈夫なんじゃね >>200
この問題
「am[0]」の使い方に違和感があるな
AMCounterクラスとか作って
カウントの責務を分離したい感じがする >>202
3つ目のクラスを作るってことか?それはまだ習ってないからそうしないのかも。 >>202
ああ。違和感あるな。これダメな設計だよなあ?
am[0].countAutomobile() や am[0].countHeavy() でカウントした結果が出るということは
new Automobile() した時にコンストラクタで Automobile クラス内にある static のクラス変数の
カウントをしていて countAutomobile() や countHeavy() メソッドでそれを読み出すという
ことになるが、そんなクラスは一つのVMで同時に一つしか動かせない。複数のスレッドで
同時に使おうとすると意図した通りに動かない。Java のクラスとしてはなんだかとても
嫌なクラスだ。 ■ このスレッドは過去ログ倉庫に格納されています