Java超｜16章のまとめ

Java超｜16章のまとめ

Javaの基礎が、見える・動く・反応するアプリへ変わる。16章は、文法やオブジェクト指向で学んだ力を、GUIアプリケーションとして形にするための大切な実践章です。

16章では、これまで学んできたJavaの文法やオブジェクト指向の考え方が、実際に「見えるアプリケーション」として形になっていく流れを学びました。

それまでの学習では、コンソールに文字を表示したり、条件分岐や繰り返しで処理を組み立てたり、クラスやオブジェクトを使ってプログラムを整理したりすることが中心でした。

System.out.println("修行を開始します");

このような文字中心のプログラムも、Javaの基礎としてとても大切です。

しかし、16章ではそこから一歩進みました。

ウィンドウを表示する。
ラベルやボタンを配置する。
ボタンやマウス操作に反応する。
画像や図形を描く。
クリックした場所に印を描く。
スレッドを使って時間とともに画面を変化させる。
そして、Javaの学習がスマートフォンアプリやWebアプリケーションのような応用分野へつながることも見えてきました。

ドラゴンボール風にたとえると、これまでのJava学習は、戦士本部の修行場で基礎の型をひとつずつ覚えてきた段階です。

変数は、任務に必要な情報を記録するスカウターのメモリ。
条件分岐は、相手の状況に応じて行動を変える判断力。
繰り返しは、同じ技を何度も鍛える反復修行。
クラスとオブジェクトは、戦士や装備、修行装置を役割ごとに整理する設計図です。

そして16章では、その基礎を使って、戦士本部の修行装置や作戦案内盤のような「見える画面」を作る段階に入りました。

ただ命令を順番に実行するだけでなく、ユーザーがボタンを押したら反応する。
マウスを動かしたら表示が変わる。
時間の流れに合わせて画面が更新される。

つまり、16章はJavaの知識が「動くアプリ」として実感できる章でした。

ここでは、16章で学んだ内容を、ドラゴンボールの世界観に置き換えながら整理していきます。

16章で学んだことの全体像

16章の内容を大きく整理すると、次のようになります。

この一覧を見ると、16章は単に「ウィンドウを出すだけ」の章ではなかったことが分かります。

最初は、空のウィンドウを表示するところから始まりました。

そこに Label や Button などの部品を配置し、ユーザー操作に反応するイベント処理を加え、Graphics で文字や図形や画像を描き、さらにスレッドで時間に合わせた変化も作りました。

流れとしては、次のように広がっています。

ウィンドウを作る
  ↓
部品を置く
  ↓
操作に反応する
  ↓
画面に描く
  ↓
時間で動かす
  ↓
応用分野へつなげる

ドラゴンボール風に言えば、最初はただの修行部屋だったものが、案内札、操作ボタン、記録盤、描画装置、自動更新機能を持つ本格的な修行装置へ育っていったような流れです。

図：16章前半 ウィンドウと部品で画面を作る

この図が示していること

この図は、16章前半で学んだ「ウィンドウに部品を配置してGUI画面を作る流れ」を表しています。

Frame はウィンドウの土台です。

そこに Label、Button、TextField、Panel、Canvas などのコンポーネントを追加して、使える画面にしていきます。

この図から分かることは、GUIアプリはウィンドウだけで完成するのではなく、部品を組み合わせて画面を作るということです。

ドラゴンボール風に言えば、空の修行部屋に案内札や開始ボタンを配置して、戦士が使える修行装置にしていくイメージです。

ウィンドウを持つアプリケーションを作れるようになった

16章の最初で学んだ大きな一歩は、ウィンドウを表示することでした。

それまでのJavaプログラムでは、コンソールに文字を出す形が中心でした。

しかし、GUIアプリでは、Frame を使って画面そのものを表示できます。

public class TrainingWindow extends Frame

Frame は、ウィンドウ本体を表すクラスです。

この Frame を継承することで、自分のクラスをウィンドウとして扱えるようになりました。

ウィンドウを表示する基本の流れは、次のように整理できます。

ドラゴンボール風にたとえると、Frame は戦士本部の「修行案内盤の土台」です。

土台を作り、名前札を付け、大きさを決め、戦士たちの前に表示する。

これが、GUIアプリの最初の形です。

ここで大切なのは、Javaのプログラムが「文字だけの世界」から「目で見える画面の世界」へ進んだことです。

ウィンドウを表示できるようになると、プログラムはユーザーが直接見て操作できるアプリケーションに近づきます。

AWTの部品を使って画面らしさを作れるようになった

ウィンドウを表示できても、何も置かれていない画面では、まだ使いやすいアプリとは言えません。

そこで学んだのが、AWTコンポーネントです。

コンポーネントとは、GUI画面に置く部品のことです。

たとえば Label を使うと、画面に案内文を表示できます。

Label lb = new Label("次の修行場へ移動します");
add(lb);

ここで大切なのは、コンポーネントは作っただけでは表示されないことです。

new Label で部品を作り、add で Frame に追加する必要があります。

ドラゴンボール風に言えば、修行案内札を作っただけで格納庫に置いていても、戦士には見えません。

それを作戦案内盤に取り付けて、色や文字の大きさを整えることで、はじめて「使える画面」になります。

イベント処理によって画面が反応するようになった

16章の中でも特に重要だったのが、イベント処理です。

イベントとは、GUI上で起きる出来事のことです。

たとえば、次のような操作がイベントになります。

イベント処理を学ぶことで、GUI画面は「ただ表示されるだけ」ではなく、「ユーザーの操作に反応する画面」になりました。

たとえば、Button を押したときに文字を変える処理では、ActionListener を使いました。

bt.addActionListener(new TrainingActionListener());

この登録によって、ボタンが押されたときに actionPerformed が呼ばれます。

イベント処理の基本構造は、次の3つで整理できます。

ドラゴンボール風に言えば、修行開始ボタンが押されると、その合図が制御係に届き、制御係が表示を切り替えるようなものです。

ボタンを押す
  ↓
イベントが発生する
  ↓
リスナに通知される
  ↓
actionPerformed が呼ばれる
  ↓
表示が変わる

この流れを理解すると、GUIの「反応する仕組み」が見えてきます。

マウスイベントでより細かな反応を作れるようになった

ボタンを押すだけでなく、マウスの動きにも反応できるようになりました。

MouseListener を使うと、次のようなマウス操作を扱えます。

たとえば、マウスがボタンに入ったら表示を変え、外に出たら元に戻す処理が作れました。

public void mouseEntered(MouseEvent e)
{
    bt.setLabel("修行メニューを選んでください");
}

public void mouseExited(MouseEvent e)
{
    bt.setLabel("修行場へようこそ");
}

このように、クリックしなくてもマウスが近づくだけで画面が反応するようになります。

ドラゴンボール風に言えば、戦士が修行案内ボタンに手を近づけると、ボタンが青白く光って案内文が変わるような仕組みです。

イベント処理を簡潔に書く工夫も学んだ

イベント処理は便利ですが、そのまま書くとコードが長くなりやすいことがあります。

特に MouseListener のように、複数のメソッドを持つインターフェイスでは、使わないメソッドも書く必要がありました。

そこで学んだのが、MouseAdapter、無名クラス、ラムダ式などの書き方です。

たとえば、ActionListener のように抽象メソッドが1つだけのインターフェイスでは、ラムダ式を使って短く書けます。

bt.addActionListener(e -> bt.setLabel("気を高めています"));

この書き方は、ボタンが押されたときの処理をすっきり書ける点が特徴です。

ただし、MouseListener のように複数の抽象メソッドを持つものは、そのままラムダ式では書けません。

その場合は、MouseAdapter や無名クラスを使うと整理しやすくなります。

描画とイベント処理を組み合わせる考え方が見えてきた

16章では、画面に文字や図形や画像を描く処理も学びました。

描画の中心になるのが、paint と Graphics です。

画像を読み込んで表示する場面では、Image、Toolkit、getImage も使いました。

Toolkit tk = getToolkit();
im = tk.getImage("training.jpg");

そして、paint の中で drawImage を使って描画しました。

g.drawImage(im, 115, 80, this);

ここで大切だったのは、画像を読み込むことと、画像を画面に描くことは別の処理だという点です。

ドラゴンボール風に言えば、getImage は修行カードをデータ保管庫から取り出す処理です。

drawImage は、そのカードを修行案内盤に貼り出す処理です。

repaintで画面を描き直す流れを学んだ

16章では、イベント処理と描画処理をつなぐ重要な存在として、repaint も学びました。

たとえば、マウスで画面を押した場所に丸を描くプログラムでは、MouseEvent から座標を取得しました。

x = e.getX();
y = e.getY();
repaint();

ここで、x と y を変えただけでは画面の見た目はすぐに変わるとは限りません。

そこで repaint を呼び、Javaに「画面を描き直してください」と依頼します。

ドラゴンボール風に言えば、GokuWarrior が修行案内盤を押すと、その場所の座標が記録されます。

ただし、記録しただけでは案内盤の表示は変わりません。

BulmaSupport が「描き直してください」と通信を送る必要があります。

その通信が repaint です。

そして paint が呼ばれ、最新の座標に気のしるしが描かれます。

図：16章中盤 イベント処理と描画がつながる

この図が示していること

この図は、16章中盤で学んだイベント処理と描画処理のつながりを表しています。

ユーザーがボタンを押したり、マウスで画面を押したりすると、イベントが発生します。

そのイベントは、登録されたリスナに通知されます。

リスナは必要な処理を行い、画面を更新したいときに repaint を呼びます。

そして paint が呼ばれ、Graphics を使って文字、画像、図形などを描き直します。

この図から分かることは、GUIアプリでは「操作を受け取る処理」と「画面に描く処理」が分かれており、repaint がその間をつないでいるということです。

スレッドによって時間の流れを持つ画面が作れるようになった

16章の後半では、スレッドを使ったアニメーションも学びました。

それまでのGUI画面は、ボタンを押したら変わる、マウスを動かしたら変わる、というように、ユーザー操作をきっかけに変化するものが中心でした。

そこにスレッドを使うと、時間の経過に合わせて画面を変化させることができます。

たとえば、修行段階を1秒ごとに変えるプログラムでは、Runnable、Thread、run、sleep、repaint、paint を組み合わせました。

public class TrainingCounter extends Frame implements Runnable

このように、Frame を継承しながら Runnable を実装することで、ウィンドウとして動きながら、スレッドで実行する処理も持てるようになりました。

スレッドによるアニメーションの基本の流れは、次の通りです。

ドラゴンボール風にたとえると、修行表示盤に時間管理係がついたようなものです。

その係が一定時間ごとに修行段階を進めます。

そして、表示盤へ描き直しの合図を送り、少し待ってから次の段階へ進みます。

スレッドと描画の役割分担

スレッドを使ったアニメーションでは、run と paint の役割を分けて考えることが大切でした。

たとえば、run の中では、step の値を更新します。

step = i;
repaint();
Thread.sleep(1000);

一方、paint の中では、その時点の step を使って文字を描きます。

g.drawString("修行段階 " + step + " に到達", 90, 150);

この役割分担をドラゴンボール風に置き換えると、次のようになります。

アニメーションは、単に文字を変えるだけでは成立しません。

値を変える。
描き直す。
少し待つ。
それを繰り返す。

この流れがあるから、画面が時間とともに変化して見えるようになります。

16章で見えてきたオブジェクト指向の実感

16章はGUIが中心でしたが、その中にはオブジェクト指向の考え方もたくさん登場しました。

ウィンドウも、ボタンも、ラベルも、画像も、イベントを処理するリスナも、すべてオブジェクトとして扱いました。

ドラゴンボール風に言えば、修行場を構成するものがそれぞれ役割を持っています。

Frame は修行場そのもの。
Button は修行開始ボタン。
Label は案内表示板。
Listener は合図を受け取る制御係。
Thread は時間を進める進行係。
Graphics は表示盤に描くペン。

それぞれのオブジェクトが役割を持ち、組み合わさることでGUIアプリが動きます。

つまり、オブジェクト指向は難しい理屈だけではありません。

役割ごとに部品を分け、それらを協力させてアプリを作る考え方です。

16章は、その実感を得やすい章でした。

Javaの応用分野へつながる入口も見えてきた

16章では、GUIやイベント処理だけでなく、その先の応用分野も見えてきました。

Javaで画面を作り、操作に反応し、描画し、時間に合わせて動かすことができるようになると、実際のアプリ開発のイメージが広がります。

ドラゴンボール風に言えば、修行場で覚えた技が、その場だけで終わらず、実戦任務や本部システム開発へ広がっていく状態です。

携帯任務スカウターのようなスマートフォンアプリ。
本部中央管理装置のようなWebシステム。
作戦案内盤のようなデスクトップアプリ。
修行記録を扱う業務ツール。

Javaの基礎は、こうした分野へ進むための土台になります。

図：16章後半 学んだ内容が応用分野へつながる

この図が示していること

この図は、16章で学んだ内容が1つの流れとしてつながっていることを表しています。

最初は Frame でウィンドウを作りました。

次に、Label や Button などのコンポーネントを置きました。

さらに、イベント処理でユーザー操作に反応できるようになりました。

その後、Graphics で文字や図形や画像を描き、repaint で画面を更新しました。

最後に、Thread を使って時間とともに画面を動かす考え方を学びました。

この図から分かることは、16章の内容がバラバラの知識ではなく、GUIアプリケーションを中心にきれいにつながっているということです。

16章を学んだあとに持っておきたい感覚

16章を終えた段階で大切なのは、「Javaで画面を持つアプリケーションが作れるようになってきた」という実感です。

もちろん、まだ本格的な実務アプリを自由自在に作るには、さらに多くの学習が必要です。

しかし、16章まで学ぶと、次のようなことが見えてきます。

ドラゴンボール風に言えば、基礎の型を覚えた戦士が、ついに本部の修行装置を自分で扱えるようになってきた段階です。

案内盤を作る。
操作ボタンを置く。
戦士の操作に反応させる。
気のしるしを描く。
修行段階を時間で進める。

こうした動きを作れるようになったことは、とても大きな前進です。

これから先へ進むための見方

16章を学んだあとは、目の前のコードだけでなく、その知識がどこへつながるのかを意識すると理解が深まりやすくなります。

この見方を持つと、16章はJava学習の終わりではなく、実践的な開発へ向かう入口として見えてきます。

ドラゴンボール風に言えば、修行場で覚えた型を、任務装置、携帯任務スカウター、本部中央管理装置、作戦案内盤の開発へ広げていく段階です。

Javaの学習は、ひとつの命令を覚えるだけではありません。

学んだ命令や仕組みを組み合わせて、画面を作り、操作に反応させ、描画し、動かし、実際のアプリへつなげていくことが大切です。

16章は、その流れを体験できる重要な章でした。