| Mr.Hack | ||
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆目次◆ ■バージョンの記述の仕方超入門
■バージョンの記述の仕方超入門 メイジャー・リリース・ナンバーが１ ということになります。Majorバージョンが変わるのは、前のバージョンともはや互換（compatible)を保てなくなった場合やデザインのし直し(redesign)した場合です。それだけ変化が劇的に変わった時に、Majorバージョンが変わります。Minorバージョンが変わるのは、新しい機能の追加があった場合や、機能の強化があった場合です。そして、Bugfixバージョンが変わるのは、新しい機能は追加していないが、その機能がちゃんと機能していないバグを修正した場合です。 これのメリットは、Major、Minor、Bugfixと種類のカテゴリーがあるので、バージョンの課程を厳密に区別することが出来ます。 しかしながら、逆に三種類のカテゴリーがあるので、バージョン管理になれていないと、どこでどうbug fixからminorへ、minorからmajorへ変わるのか定かでなかったり、前回のバージョンを記載し忘れたりした場合に誤ったバージョンを記載してしまう場合もあります。たとえば、1.3.1から1.3.4になってしまう場合などです。 それを補うように、ある意味オートメーションにしたのが、メイジャー・リリース・ナンバーの後に、日付ナンバーを記載する方法です。例えば、バージョンナンバーが1.0601とあれば、 メイジャー・リリースナンバーが１ ということになります。これは、手作業でバージョン情報を記入しなくてよく、 ただ、一つ問題があります。その問題とは、年に一度、必ずメイジャーバージョンを変えないといけないことです。そうしないと、来年の３月１日にアップデートすると1.0301となり、1.0601よりバージョンが古くなり矛盾が生じてしまいます。 このメルマガが何年にわたって続くとは思っていないので（つづくといいですが）Mr.Hackは後者のバージョン情報記述方法で記載していこうと思います。また、同じ号のメルマガで同じクラスで変更が生じた場合、サブナンバーを最後につけるかもしれません。この記述方法だと前回のメルマガに乗っているバージョンはいくつだったっけ？と確認する時間が省けとっても便利なのです。 皆さんも、プログラムに記述するバージョン情報で最初は一般的な記述方法はちょっとめんどくさいな、という場合は後者の日付式バージョン方法で記載してみてください。後から記述しようとおもって、記述し忘れるのが一番良くありませんからね。 ■@see、@linkタグ ┌──────────────────────────────────┐ @see 参照先のクラス等 (その記述） └──────────────────────────────────┘ です。参照先にはクラス・インターフェイス・メソッド・フィールドを指定できます。メソッド・フィールドを指定するときはクラスの後に、『#』を入れます。また、その後、オプションでクラスで記述すると、その記述したコメントにリンクが張られます。上記がjavadocで実行されると、 ┌──────────────────────────────────┐ 関連項目: @linkは、@seeタグと機能は同じですが、コメントの中でリンクを張りたいところにどこでも使うことが出来ます。記述方法は、 ┌──────────────────────────────────┐ で、例では、『BankAccountとBankAccountのwithdraw()メソッド』と表示され、それぞれ、BankAccount、BankAccountのwithdraw()メソッド、にリンクが張られます。 ■@deprecatedタグ それの解決してくれるのが、@deprecatedタグです。使用方法は、 ┌──────────────────────────────────┐ @deprecated 推奨されない理由等の記述 です。そこに記述すべきことは、推奨されない理由、いつのバージョンから代替メソッドに切り替わったか、代替メソッド先へのリンク等です。 @deprecatedタグの特筆すべきことは、コンパイラーがコンパイル時にこのタグがあることをclassファイルに記述しておくことです。普通コンパイラーはコメントされたところは、全て無視してclassファイルに書き込むことはありません。このclassファイルにノートを書き込むことによって他のクラスがこの@deprecatedタグをもったクラスをコンパイル時に参照使用とすると、 ┌──────────────────────────────────┐ └──────────────────────────────────┘
実際に警告を見てみましょう。 まずは、前回vol.008のBankAccount.javaとBankAccountTest.javaをCPadをつかって開いて下さい。そして、メニューの『実行』→『エクスプローラーを起動』を選択し、エクスプローラーから、BankAccount.classとBankAccountTest.classが存在していれば、削除します。 次に、CPad上でBankAccount.javaのタグを選び、左から４番目の『make or コンパイル』アイコンを押して、BankAccount.javaだけコンパイルします。これで、このクラスファイルに@deprecatedのノートが書き込まれました。 次は、BankAccountTest.javaを同じようにコンパイルします。すると、 ┌──────────────────────────────────┐ └──────────────────────────────────┘ と警告がでます。しかしながら、先ほど開いたエクスプローラでフォルダを見てみるとBankAccountTest.classが生成されていますので、コンパイルは出来ました。もちろん実行ボタンを押すとBankAccountTestクラスが実行されテスト結果がスクリーンに表示されます。 -deprecationオプションを使って、BankAccountTest.javaをもう一度コンパイルしてみましょう。CPad上のメニューの『実行』→『コマンドプロンプトを起動』 ┌──────────────────────────────────┐ とタイプすると、 ┌──────────────────────────────────┐ bankaccounttest.java:118: 警告: BankAccount の getBlance()
は と警告が発せられます。これによって、getBlance()メソッドが推奨されないことをユーザーに知らせ、使うべきではないことをユーザーに暗に伝えることが出来るのです。 ■JavaドキュメントはHTML 使用していて結構便利なのは、<PRE>だと思います。Javadocで生成されるコメントは、半角スペースがあっても、それを取り除かれてしまうのでコードを書くとみんな左寄りになってしまいます。それを<PRE>でくくってあげると、半角スペースを含めた、コードを生成してくれます。 ┌──────────────────────────────────┐ ■javadocコマンドオプション ┌──────────────────────────────────┐ とタイプします。そうすることで@author、@versionタグで記述した内容が出力去れいます。 今回は全てのコマンドオプションにはふれませんが、コマンドオプションにはどんなモノがあるかみたい場合は、 ┌──────────────────────────────────┐ とタイプするとオプション群を見ることが出来ます。 今回は、Java ドキュメントについて見てきました。これで、皆さんはいつでもJavaドキュメントを作成できますね。これは、一義的にはあなたのプログラムを見るユーザーのためではありますが、あなた自身のためでもあることを常に念頭において、めんどくさがらず作成して下さいね。 さて最後に、今週の宿題です。今回は次回のユーザーインターフェイス作成のウォーミングアップをしましょう。 ■Question 9 コンソールベースのメニューを扱うBankUserInterface.javaを作成しなさい。
ただし、BankAccount.javaのインスタンスを使用してはならない。 ヒント： Mr.Hackコーポレーションの社員であるあなたは、この２ヶ月でJavaのプログラムの基礎を勉強し、いよいよ、配属が決まりました。配属先は、ユーザーインターフェイスを作る部署です。ここでは、バックエンドである、BankAccountクラスのようなAPIは作成しません。ユーザーがいかに使いやすくプログラムを使用できるかが、最大のテーマです。あなたは、目に見えるユーザインターフェイスの作成にわくわくです。 あなたは、BankAccountクラスを今現在では使えないことが分かりました。というのも、ここのプロジェクトチームとバックエンドのBankAccountクラスのようなAPIを作成するプロジェクトチームとのプログラムの実際の調整はまだ先なのです。バックエンドプロジェクトチームからは、BankAccountクラスのAPI仕様書しか渡されていません。あなたは、上司にどうやって、BankAccountクラスがないのにコンパイルするのだと尋ねました。BankAccount.classがなければ、一緒にコンパイルすることは出来ないからです。 上司は、バックエンドプロジェクトチームから、実際に使うところは、コメント//をつかって // bankAccountOjbect.deposit(amount); というようにダミーをプログラムに置くように指示がでていると教えてくれました。あなたは、はやく完成されたBankAccountクラスをわたしてくれー！とおもいながら、渋々プログラムにかかります・・・。 いよいよ来週はユーザーインターフェイスの部分の作成に取りかかります。しかしながら、プログラムの規模が大きくなるとプロジェクトチームベースで一つのアプリケーションに取りかかります。プロジェクトチームはユーザーインターフェイスを作るチーム、バックエンドのロジックをになうチーム、はなまた、データベースとのコネクションをになうチームというように、別々のチームが別々にプログラムをしていきます。そして、それぞれが完成したら、プロジェクトチームが一緒になって実際に運用します。そのため、その運用までは、仕様だけ渡され、その仕様に沿ってプログラムを作成します。初心者の方には、なんとも、全て完成しないようで歯がゆいところがあるのは事実ですが、今回は、練習もかねて、BankAccount.javaをBankUserinterface.javaと同じフォルダに置かないで、ユーインターフェイスの部分のみ作成して下さい。 宿題や、メルマガでわからないところがあれば、 http://fweb.midi.co.jp/~romanhikou/cafe_entrance.html の掲示板から質問して下さい。今回のユーザーインターフェイスのヒントになるコードもおいてありますので、参考にしてみるといいかもしれません。
Mr.Hack
|
||
| © 2002 MR.HACK ALL RIGHTS RESERVED | ||