カプセル化と例外。
ちくしょぉー…
カードコンテンツまで、やられてたぁぁぁ(涙)
何が?って、奥さんっ、
先日のサーバートラブル時に、
いろいろ勝手に設定変更された影響で、
カードコンテンツも動かなくなってたんですよ。
それを今更気付くなんて。しくしく。
もうこうなりゃ、全部オブジェクト指向で書き直してやるーっ。
って訳で(^^;
今日もJava学校だったので、授業メモでーす。
まずは前回書かなかったカプセル化から。
続いて、今回のテーマ、例外処理。
情報を隠蔽する事(^^;
オブジェクト指向の大きな特徴。
私の一番素晴らしいと実感する事は、
メンバ変数への操作を、すごく限定する効果だと思う。
クラスのメンバ変数を、
外部からコロコロ簡単に変更できるようだと、
エラー発生時に、一体どこで何をどう操作した時に
問題が起きたのか、わかりにくい。
おまけに、予想外の文字列とか代入されちゃった日にゃ
エラー出るのは当たり前。
メソッドに関しても、
想定してない環境下で使われてしまえば、
同じくメンバ変数に変な影響が出る可能性大で
やっぱりエラーの素。
だから、外部から情報をどこからでも操作されにくいように
メンバ変数やメソッド、クラスに対して、
アクセス出来る範囲を狭めたり、限定する事によって
外部から見て「隠蔽」されている状態にしようとしてるんではないかと。
そこで登場するのが、アクセス修飾子と
getter と setter。
・アクセス修飾子
クラス・インターフェース・メンバ変数・メソッドなどが
呼び出される事の出来る範囲を定める修飾子。
例)
public class Test {
private int testNum;
public void setTestNum( int testNum ) {
this.testNum = testNum;
}
}
Testクラスは public なので、外部からアクセス可能
testNumメンバ変数は private なので、このクラス内でしかアクセス出来ない
setTestNumメソッドは、public なので、外部からアクセス可能
- アクセス修飾子の意味
- public
どこからでも呼び出し可能
- protected
同じパッケージと継承クラスのみ呼び出し可能
- 無指定
同じパッケージ内からのみ呼び出し可能
- private
クラス内からのみ呼び出し可能
・getter と setter
メンバ変数に値を代入したり(setter)、
値を参照する(getter)メソッドのこと。
メソッド名は、get変数名、set変数名 が定番らしい。
なお、Eclipse には、自動的に getter と setter を
各メンバ変数毎に生成する機能がついている。
「ソース」メニューの「Getter および Setter の生成...」
・例外処理
例外…と言われると、ピンと来ないけど
早い話、エラー対処するルーチン。
※perl では Errorモジュールを使うと例外処理できる。perl6 で対応?
※PHP では 5以上で使える
エラーと言っても種類があって、
例えば、ユーザーの入力したユーザー名が
「最大6文字」って書いてあるのに、7文字だったりすれば
それも一応、エラーの一種。(非検査例外)
「ユーザー名は6文字以内で記入してください」とか
アナウンスせなアカンです。
対して、ユーザーは正しい処理をしているのに、
存在するはずのファイルがなかったり、
連携を取るはずのサーバーがダウンしてたり…という、
ユーザーには、どうする事も出来ないエラーもあるし。(検査例外)
はたまた、プログラマーもユーザーも
全く予想出来ないトラブルのエラーもある。
…と、例外の種類毎に対処方法が違うのだけど
「検査例外」の種類には、この↓例外処理で対処せなアカンらしい。
try {
// 例外の発生する可能性のあるスクリプト
} catch( 例外オブジェクト名 参照変数名 ) {
// 例外発生時に振る舞い
} finally {
// どんな時でも、必ず実行する部分
}
try の中のスクリプトで
何か例外が発生すると、
例外オブジェクトが自動的に生成されるらしい。
その例外オブジェクトの名前は、
それぞれの例外の種類によって違うので、
API仕様でチェックせなアカンらしい(^^;
で、その例外オブジェクトを
参照している変数も、これまた自動で出来るので
catch( 例外オブジェクト名 参照変数名 )
のところで、参照変数名に
e とか ex とか、名前をつけておいてやるそうな。
(※ Exception(例外)の頭文字を取っているらしい)
例外が発生した時には、その e とか ex から
getMessage() とか、printStackTrace() メソッドで
エラー内容が取得できるので、
catch 文の下の行で、
それをアナウンスしても良し、エラーログに書くも良し。
とにかく、例外発生時の処理を書く、と。
なお、printStackTrace() は冗長なんで
Java Tips:例外メッセージをカスタマイズして表示するには
なんかを参考にすると良い模様。
catch 文は何個あってもOKらしいが、
万が一「どんな例外でも、どんと来い」な catch文が必要なら
catch( Exception e )
とか書けばいいそうな。
要するに、どんなクラスも Objectクラスを継承しているように
どんな例外クラスも Exceptionクラスを継承してるんだってさ。
さて、finally 文の部分は、省略可能だけど
try文のどっかで return しようが、
例外が発生しようが、どんな場合でも実行するから、
結構使えるのではないかと思ったり。
こんな感じかなぁ…今日は。
本当はArrayListも習ったけど、
それは次回授業とまとめてって事で。