はてなブックマーク

インタフェースのキャストは特殊です。 クラスの場合、「8.5 キャストできる？　できない？」で説明したように、「継承関係が明確な場合」のみキャストが可能です。コンパイラは参照型変数の型を見て、「継承関係にあるはずがない型」へキャストしようとした場合にコンパイルエラーを出して「多分ダメだよ」と教えてくれていました。 ところが、インタフェースの場合は別です。 普通のクラスの参照型変数からインタフェースの参照型変数へのキャストは、コンパイルエラーになりません。 実際に試してみましょう。 // AClassRunner.java /** * とあるインタフェース。 */ interface AnInterface { void printMyName(); } /** * とあるクラス。 */ class AClass { void print() { System.out.println( "A

ダウンキャストの可否 質問：キャストしようとしたらコンパイルエラーになりました。 解答：キャストした時に、コンパイルエラーになる場合と、実行時に例外が投げられる場合があります。 クラス関係が複雑になり、さらにダウンキャストしまくると、キャストがコンパイルエラーになったり実行時に例外が投げられたりと、事態が複雑になっていきます。 どういう時にうまくいって、どういう時にうまくいかないのか分けて考えてみましょう。 // RightSubRunner.java /** * 何も持たないクラス。 */ class RootSuper { } /** * 何も持たないクラス。 * RootSuperクラスのサブクラス。 */ class LeftSub extends RootSuper { } /** * 何も持たないクラス。 * RootSuperクラスのサブクラス。 */ class Right

staticで修飾されたメソッド。 「static 戻り値 メソッド名(引数){ 実装 }」のように、メソッドの宣言の先頭にstaticが付けられたメソッド。 staticメソッドは、呼び出す際にインスタンスを必要としない。 「クラス名.メソッド名()」の形式で呼び出すことができる。呼び出すstaticメソッドが自クラスにある場合には、呼び出し元のメソッドがstaticメソッド、非staticメソッドに関わらず呼び出すことができる。 通常のメソッド（非staticメソッド）は、ポリモーフィズムの関係で「インスタンス作成時に呼び出すメソッドが決められる」事もあり、メソッドの呼び出しにはインスタンスが必ず必要となる。 だが、staticメソッドはインスタンスではなく「クラスに属するメソッド」のため、インスタンスを作らずに直接呼び出すことができる。 インスタンスと関係ないため、自クラスのインスタ

// HasStaticAndNormalMethodRunner.java /** * staticメソッドと普通のメソッドを持つクラス。 */ class HasStaticAndNormalMethod { // int型変数のstaticフィールドdataStaticを定義します。 static int dataStatic; // int型変数のフィールドdataNormalを定義します。 int dataNormal; /** * フィールドを出力するstaticメソッドです。 */ static void staticPrintData() { // staticフィールドを出力します。 System.out.println( dataStatic ); // 普通のフィールドを出力します。 // System.out.println( dataNormal ); // コン

画面表示に使用する「部品」クラスの仕様。 Javaにおいて最も分かりにくい仕様のひとつ。 画面表示に使用するクラスを、「部品」として再利用できるようにするため決められた「仕様」が「JavaBeans」である。 JavaBeansの仕様に則して作られたクラスを「Java Bean」もしくは単に「Bean」「ビーン」と呼ぶ。 「画面表示」とは広義のGUIを指し、ウィンドウアプリケーションからWebアプリケーションまで含む。また、直接画面表示をする必要はなく、「画面表示のための部品となるクラス」であればなんでも当てはまる。 実際、現在最も使用頻度の高いJavaBeansの使用方法は、Webアプリケーションでの利用である。 サーブレット側で「画面に出力するための情報」をJava Beanクラスに格納し、HttpServletRequestインターフェイスかHttpSessionインターフェイスのs

例外が発生した「本当の原因」。 ThrowableクラスやExceptionクラスは、コンストラクタで別の例外を格納することができる。この例外はgetCause()メソッドで取得でき、printStackTrace()メソッドで出力すると「Caused by:」に続けて出力される。 通常、この例外には「本当の原因」の例外を格納する。 例外は、throwsにより指定されたクラスしかメソッドから投げられることはない。そのため「実際に投げたい例外」と「throwsで投げられる例外」が異なる場合がある。その場合、throwsで指定された例外を投げ、その例外のインスタンスを作成する際にコンストラクタで「実際に投げたい例外」を渡すという方法を取ることができる。この方法により、デバッグ時に「本当の原因」を知ることができる。 ただし、「実際に投げたい例外」と「throwsで投げられる例外」が大きく異なる場

// ImplementedAndSubRunner.java /** * 計算をするインタフェース。 */ interface CalcInterface { /** * 抽象メソッド。 */ int calc( int lh, int rh ); } /** * 足算機能を持つクラス。 */ class AddSuper { /** * 足算します。 */ int add( int lh, int rh ) { return lh + rh; } } /** * CalcInterfaceインタフェースの実装クラスでかつ * Addクラスのサブクラス。 */ class ImplementedAndSub extends AddSuper implements CalcInterface { /** * 抽象メソッドをオーバーライドします。 */ public int calc( in

インスタンスの「文字列表現」を返すメソッド。 インスタンスの内部に格納されたデータも含めて文字列化し、Stringクラスの戻り値として返すメソッド。 引数なし、戻り値の型はStringクラス。 この戻り値の文字列にはインスタンスの「概要」が書かれていることになり、インスタンスについて簡単に情報を得ることができる、便利なメソッドである。 toString()メソッドは多くの場面で呼び出される。 たとえば、println()メソッドは渡されたインスタンスのtoString()メソッドを呼び出し、返された文字列を出力する。 また、Eclipse等の開発環境でデバッグ時に変数を見ようとすると、その変数がクラスの参照型変数の場合にはtoString()メソッドが呼び出され、返された文字列がウィンドウに表示される。 toString()メソッドのおかげでインスタンス内の状態を簡単に知ることができ、デバ

特定のメソッドが呼ばれるまでに経てきたメソッドの一覧。 あるメソッドは、通常他のメソッドから呼ばれ、そのメソッドも他のメソッドから呼ばれ、そのメソッドも他のメソッドから呼ばれ……と続き、最終的にはmain()メソッドから呼ばれている。 この「あるメソッドが呼ばれるまでの、メソッドの呼び重ね」は全て保存されている。 このメソッドの情報は、それぞれのメソッドに格納されたローカル変数と共に「スタック」形式でメモリ（スタック領域）に格納される。ローカル変数は最後に呼ばれたメソッドの変数から消されるためである。 この「メソッドの呼び重ね」の一覧を「スタックトレース」と呼ぶ。 スタックトレースは、例外が投げられたときに、投げられた箇所を特定するために出力することが多い。 スタックトレースは、ThrowableクラスのprintStackTrace()メソッドで標準エラー出力に出力できる。また、getS

J2SEに含まれるインタフェースのひとつ。パッケージも含めたインタフェース名はjava.lang.Iterable。 拡張forに渡せるようにするためのインタフェース。 このインタフェースの実装クラスは、拡張forに渡すことができるようになる。 Iterable<T>インタフェースはiterator()メソッドを持つため、このメソッドを実装する必要がある。 拡張forに渡すと、拡張forの内部でiterator()メソッドが呼び出される。 iterator()メソッドはイテレーターを返すよう実装しなければならない。この返したイテレーターを使用して、拡張forはループを行う。逆に言えば、「拡張forでループしたい配列やコレクション」のイテレーターを返せばよい、ということである。 Iterable<T>インタフェースはジェネリッククラスである。型引数には、iterator()メソッドで返すイテ

前ページでは、インタフェースとクラスは別、ということを説明しました。 では、なぜこのように、クラスとインタフェースは分けられているのでしょう。 それは、インタフェースがインスタンスを作らないからです。 クラスは、インスタンスを作るための「設計図」です。newでインスタンスを作るための情報、それがクラスです。 ところが、インタフェースにはその機能がありません。 インタフェースはインスタンスを作りません。 まず、インタフェース単体では当然インスタンスを作れません。 また、インタフェースの実装クラスを元にインスタンスを作っても、その中に「インタフェースから作られたインスタンス」は含まれていません。 それを、プログラムを通して見てみましょう。 // InheritedFromObjectRunner.java /** * インタフェース。 */ interface HasToStringInter

// AbstractClassRunner.java /** * 抽象クラス。 */ abstract class AbstractClass { /** * 抽象メソッド。 */ abstract void printMyName(); } /** * 実行用クラス。このクラスを実行してください。 */ class AbstractClassRunner { public static void main( String[] args ) { // 抽象クラスはインスタンスを作れません！ // AbstractClass ref = new AbstractClass(); // コンパイルエラー： // AbstractClassRunner.java:18: //     AbstractClass は abstract です。 //     インスタンスを生成することはできません

ここまで、グローバル変数や構造体の問題点を見てきました。 では、オブジェクト指向プログラミングを使ってこの問題点を改善していきましょう。 「カプセル化」する まずはオブジェクト指向プログラミングの一機能「カプセル化」を使ってみましょう。 具体的には、「3.5 GetterとSetter」で紹介したGetterとSetterを使って、フィールドを守ってみます。 // AccessorRunner.java /** * フィールドをprivateにして、 * GetterとSetterを持つクラス。 */ class Accessor { /** * privateフィールドx3。 */ private int data1; private int data2; private int data3; /** * そのGetterとSetter。 */ public int getData1()

// HasStaticAndNormalFieldRunner.java /** * staticフィールドと普通のフィールドを持つクラス。 */ class HasStaticAndNormalField { // int型変数のstaticフィールドdataStaticを定義します。 static int dataStatic; // int型変数のフィールドdataNormalを定義します。 int dataNormal; } /** * 実行用クラス。このクラスを実行してください。 */ class HasStaticAndNormalFieldRunner { public static void main( String[] args ) { // staticフィールドに数値を入れます。 HasStaticAndNormalField.dataStatic = 1; // 

前ページでオブジェクト指向プログラミングのメリットについて紹介しました。 引き続き、メリットについて見ていきたいと思いますが、そのために、まずずっと昔に行われていたプログラムの作り方を振り返り、今のオブジェクト指向プログラミングまで見ていくことにしましょう。 グローバル変数 プログラムを動かす時には、大量のデータを管理する必要があります。 ファイルやデータベースとやりとりするデータ、画面から入力したデータ、処理途中のデータ、サーバー内部にずっととっておくデータ、各種設定、ログ等、様々なデータを内部で管理します。 そういった大量のデータをどう管理するか、がプログラムそのものを管理することに継ながります。 でも、最初はダメダメでした。 「グローバル変数」という、どこからでも自由にアクセスできる変数にデータをつっこんで使うという方法を、最初は採っていました。 Javaには正確な意味でのグローバル

浮動小数点を必ずIEEE754で扱うための予約語。 クラスもしくはメソッドを修飾することで、そのクラス内及びメソッド内での浮動小数点の扱いは、必ずIEEE754の仕様に則ったものとなる。 逆に言うと、strictfpで修飾されていない場合、厳密にIEEE754の仕様に則っていない場合がある。これは、浮動小数点の計算は、実際にはJavaではなくCPUが行い、浮動小数点の計算結果がCPUの仕様に依存するためである。 strictfpはこの問題を解決し、常にIEEE754の仕様に則った結果をもたらす。ただし、そこまでこだわるのであれば、動作速度が許せばBigDecimalクラスを使用した方がいいだろう。 // Sample.java public class Sample { public static void main( String[] args ) { Sample sample = n

J2SEに含まれるクラスのひとつ。パッケージも含めたクラス名はjava.util.ResourceBundle。 リソースバンドルを使用するためのクラス。 ResourceBundleクラスのgetBundle()メソッドで「プロパティファイル名」を指定することで、クラスファイルと同じディレクトリに置いてあるプロパティファイルの中から、適切なロケールのファイルを探し出して取得する。 実際の値の取得は、getString()メソッドでキーを指定することで取得する。 厳密には、ResourceBundleはプロパティファイル「も」取得できるクラスであり、プロパティファイル専用のクラスではない。が、実際にはプロパティファイルを取得する場合によく使われる。 // Sample.java import java.util.ResourceBundle; public class Sample { p

J2SEに含まれるインターフェイスのひとつ。パッケージも含めたインターフェイス名はorg.w3c.dom .Node。 DOMに含まれるインターフェイスのひとつ。 「ノード」を操作するためのインターフェイス。 XMLのパーシングを行う際に使用するインターフェイス。 XML中のタグや文を「ノード」、つまり「枝」と見なして扱う。XMLは木構造をしており、その木の「枝」を扱うのがNodeインターフェイスである。 ノードは、タグを表す「エレメント」や、文を表す「テキスト」の総称である。 つまり、XMLの「ノード」は、タグであったり文であったりする。これらをまとめて「ノード」と表現する。 それにならい、NodeインターフェイスはElementインターフェイスやTextインターフェイスのスーパーインターフェイスとなっている。 取得したNodeインターフェイスは、getNodeType()メソッドで「エ

処理を委託され、その処理を行うクラスもしくはメソッド。 「全体の機能」に対して「一部の処理を、ユーザーもしくはプログラマーが任意に変更できるようにする」ために使用されるのがハンドラである。 ハンドラは通常はインターフェイスとして用意され、ハンドラクラスはそのインターフェイスの実装クラスとして作り、メソッドを実装する。 このクラスを「全体の機能」に登録しておくと、「全体の機能」は「一部の処理」を行う際にハンドラクラスのメソッドを呼び出す。 このような仕組みにすることで、「全体の機能」を作り直すことなく「一部の処理」だけを追加したり切り替えることができる。 主なハンドラに「イベントハンドラ」がある。 イベントハンドラは、イベントが発生した際にメソッドが呼び出され、そのイベントに対応した処理を行うことができる。 この例であれば、GUIのシステムが「全体の機能」、イベントに対応する処理が「一部の処

スタックトレースを出力するメソッド。 Throwableクラスのメソッド。 投げられた例外の「例外クラス名」、コンストラクタで渡された「例外の説明」、呼び出し元メソッドとファイル名及び行番号（つまり「スタックトレース」）、「Caused by」の4つを標準エラー出力に出力する。 例外が投げられた理由を簡単に取得できるため便利。デバッグの友。 引数を渡さずに呼び出すと標準エラー出力に出力される。 引数にPrintWriterクラスを渡すと、渡した文字出力ストリームを通して出力されるため、文字列やファイル等、好きな出力先を選択することもできる。 // Sample.java import java.io.PrintWriter; import java.io.StringWriter; public class Sample { public static void main( String[

// AddedSub2Runner.java /** * 普通のクラス。 * （NormalSuperクラスと全く同じクラスです） */ class NormalSuper2 { // int型変数のdataフィールドです。 int data; /** * フィールドを出力するメソッドです。 */ void printData() { System.out.println( data ); } } /** * NormalSuper2クラスから継承した、サブクラス。 * フィールドとメソッドを追加しています。 * （AddedSubクラスと全く同じクラスです） */ class AddedSub2 extends NormalSuper2 { // int型変数のdataSubフィールドです。 int dataSub; /** * フィールドを出力するメソッドです。 */ void pr

インスタンス1はmethodA()メソッドとmethodB()メソッドを持っています。 インスタンス2はmethodA()メソッドとmethodC()メソッドを持っています。 こんなインスタンスがあれば目的のプログラムが動く、と考えたわけです。 さて次に、これらのインスタンスから機能（フィールドやメソッド）を抜き出して、共通の機能を図にします。 インスタンス1とインスタンス2は、共通の機能としてmethodA()を持っています。なので、このmethodA()メソッドを大きな円（ピンク）の中に書きます。 その大きな円の中に小さな円を2つ書き、インスタンス1とインスタンス2それぞれの機能を書きます。 インスタンス1だけの機能はmethodB()メソッドなので、これを小さい円の1つ（橙）に書きます。 インスタンス2だけの機能はmethodC()メソッドなので、これを小さい円の1つ（緑）に書きます

// GetterAndSetterRunner.java /** * GetterとSetterを持つ、標準的なクラス。 */ class GetterAndSetter { // int型変数のフィールドです。privateです。 private int data; /** * フィールドの値を取得します。 */ public int getData() { return data; } /** * フィールドに値を入れます。 */ public void setData( int param ) { data = param; } } /** * 実行用クラス。このクラスを実行してください。 */ class GetterAndSetterRunner { public static void main( String[] args ) { // GetterAndSetterクラス

ＦＡＱの中でもトップクラスと言って間違いない「ショートカット」。ですが、それなりにちゃんとしたアンサーがないような気がするのは筆者だけでしょうか？　そんな感じでいってみましょう。 ショートカットに使うインターフェイス ショートカットの操作に必要なのはIShellLinkインターフェイスと、IPersistFileインターフェイスです。ひとつだけじゃダメなのがみそです。ちなみに、これまで通りどっちもポインタとして扱いますが、LPなんたらという形にどちらもなってないんで注意。 まぁ、そんな感じで次のようにメンバ変数として持っておいてください。 IShellLink *m_pShellLink; //IShellLinkへのポインタ。 IPersistFile *m_pPersistFile; //IPersistFileへのポインタ。 BOOL CT_Filer2View::LinkInit(

main()メソッドの引数に使用されることの多い変数名。 main()メソッドの引数、Stringクラスの配列の変数名。多くの例でこの変数名が使用されている。 「arguments」の略。 別にこの変数名でなくても良く、自由な変数名を付けることができる。main()メソッドとして「呼ばれるための条件」に、変数名は含まれていないためである。 この引数には、javaコマンドによる実行時に指定された文字列が渡される。 指定された文字列はスペースで分割され、各単語が各要素として格納される。 // Sample.java public class Sample { //                                 ↓これ。 public static void main( String[] args ) { // argsには、javaコマンドに渡された文字列が // 格納されて