オブジェクト指向プログラミング演習

第1回 オブジェクト指向とJava

2019.04.11

プログラミング学習の段階

⚫ 命令が実行される様子の理解

⚫ 個々の命令の意味の理解

⚫ 一連の命令の並びが、全体として何をしているか理解する

⚫ 計算機にさせたい作業の全体を命令の並びで表現する

⚫ 協働作業で大きなソフトウェアを作る（ソフトウェア工学）

2019.04.11

文法や単語を覚える

長文の読解長文の作文

語学に例えると…

共著で本を書く

隔たり

隔たり

オブジェクト指向が

威力を発揮する範囲

2019.04.11

本演習の目標

⚫ ひとまとまりのプログラム全体を自力で作る

◆作りたいモノをプログラムとして書き下す過程を学ぶ

◼作りたいモノを明確にする（分析）

◼作りたいモノを構成する部品とその組み合せ方を考える（設計）

◼プログラムとして実現する（実装）

⚫ オブジェクト指向を学ぶ

◆分析や設計から実装まで、対象を同じように考える方法（の一つ）を修得する

◆残念ながら「協働開発」まではいかない

本演習について

⚫ オブジェクト指向の考え方を学ぶ

⚫ オブジェクト指向の考え方に沿ったプログラミングを学ぶ

◆プログラミング言語としてJavaを使う

⚫ 参考書：

2019.04.11

半田久志 著, "Java と UML で学ぶオブジェクト指向プログラミング", 近代科学社, 2014

演習室：セキュリティ演習室

各自、自分のノートPCを有線LANにつなげて使う

⚫ ノートPCを必ず持参すること

⚫ 使用する言語は Java

◆VMWare Player と ubuntu のインストールをしておくこと

◆ubuntu に Java の開発環境をインストールしておくこと:

sudo apt-get install default-jdk

◆ubuntu には emacs などのテキストエディタをインストールしておくこと

2019.04.11

本演習の成績評価について

⚫ 出席(約20%)と演習(約30%)

◆毎回、出席を確認する

◆出席確認はだいたい演習を兼ねる

⚫ 課題(約50%)：レポートを課す

◆時間をかけて少し大きめのプログラムを書く課題を出す

◆同じテーマで2回提出（両方出して50%）

⚫ 期末試験は実施しない2019.04.11

去年までとは、やり方を変えました

今日のお題

⚫ プログラミングという行為の ある一面

⚫ モジュール化

⚫ オブジェクト指向

⚫ Java

2019.04.11

←これは目標であって、厳密に決める必要はない

プログラミングという行為

手順を曖昧さなく表現する

そのためには？

➡作りたいモノの仕組みを、きちんと理解・決定する

◆どう動くのか？

◆どういう仕組み・手順で、その動きが実現されるのか？

仕組みを理解するためには？

➡作りたいモノを、部品に分ける

◆複雑なモノの全体を一度に理解するのは難しい

◆全体は、どんな部品を、どう組み合わせてできているか？

◆各部品は、どうできているか？ 2019.04.11

この二つに大きな違いがあることは学んだはず

仕組みが分からなければ、作れない。「仕組み」が重要。

プログラムの書き手が考えるべき範囲

⚫ プログラムの全体

部品への分割・組み合わせ方

⚫ その部品

◆さらにその部品…

部品への分割・組み合わせ方

⚫ 用意された部品

◆部品の使い方

◆用意された部品の中身

◼計算方法・OSの機能・ハードウェアの仕組み

⚫ 外部とのやりとり

◆外部=OSやハードウェアの向こう側

◆ユーザ（人間）・他のプログラム 2019.04.11

プログラムに直接反映される。

(内部設計）

プログラムの使い方に関わる。

(外部設計）

知っておくと、• 部品の使い方の

理解が早い。• より良い方法を

考える素養になる

部品とその組み合わせ方が

「仕組み」

• 外部の動作が、それを受け取る部品にどう反映されるか。

• どの部品を使うと外部に情報を提示できるか。

部品に分けるときの考え方

⚫ プログラムの全体

⚫ プログラムの部品

⚫ 用意された部品

2019.04.11

To

p D

ow

n

Bo

tto

m U

p

※）部品をモジュールと呼び、

全体をモジュールに分けることをモジュール化と呼ぶ

プログラム全体が持つべき機能をもとに、その機能を実現する部品を考える

用意された部品が持つ機能をもとに、その機能を使って実現できる部品を考える

プログラム全体が持つべき機能を

考える

どんな機能が提供されているかを

知っておく

大きなプログラムを書くには、部品を考えることが重要。

プログラムの書き手が部品を決める

用意された部品を使うために必要な情報を準

備する

分析・設計・実装

分析：やりたいことを整理する

◆どんな機能を持つのか

◆本質（必要最小限の機能）は何か

設計：仕組みを考える

◆外部とどうやりとりするのか（外部設計）

◆どんな部品をどう組み合わせるのか（内部設計)

実装：プログラムを書く

◆設計の通りに…

2019.04.11

大きなプログラムを一気に書くことはできません。設計や実装の優先順位をつけることにも意味があります。

分析と部品への分け方の例

テトリスを作りたいとする

⚫ 画面を表示したい

◆画面表示という機能が必要

◆あたりまえのことをきちんと意識するのも分析

⚫ 「画面を表示する」部品を考える

◆画面には、盤面とブロックを表示する

◼画面表示の部品は、盤面表示とブロック表示

◼どちらもマスを表示する

マスの表示という部品が共通して使える2019.04.11

プレイヤーではなく、ゲームの方

テトリスのプログラムが持つべき、たくさんの機能のうちの一つ

2019.04.11

本質的な機能とは？（テトリスの例で）

画面表示は機能の一つ

⚫ 人間がプレイするなら、画面表示が（たぶん）必要

⚫ プログラムがプレイするだけなら、画面表示は不要

◆プログラムに対して状況を伝える手段が必要

テトリスというゲームが本質

⚫ ゲームの状態（盤面やブロック）を管理する機能

◆状態を情報（データ）として記憶する

◆状態を時間経過やプレイヤの操作によって変化させる

…対象を(データで)表現することをモデル化と呼ぶ

➡ 本質的なプログラミングとは：

◆状態をデータで表現すること

◆状態の変化に応じてデータを更新する機能を作る

プログラムの部品

⚫ 手順を構成する小さな手順

◆C言語の関数

⚫ 手順と、その手順が操作するデータには、密接な関係がある

◆まとめて扱えたら分かりやすい

➡ オブジェクト指向という考え方へ

2019.04.11

抽象データ型という概念

モジュール

2019.04.11

余談：「設計」について

NHKスペシャル「東京リボーン第1集」の中のセリフ

設計通りに作れることはない。なんとかするのが職人のウデ。

⚫ ソフトウェアでも同じことが言えそう

◆身も蓋もないが、真理だなぁ

◆「…ない。」は言い過ぎかな…

⚫ とは言え設計は大事

◆職人だって設計通りに作れるほうが楽なはず

◆設計通りに作れないのは、設計者の怠慢・勉強不足

◆コードまで見通してソフトウェアを設計すべき

東京五輪に向けた巨大建造物の建築現場の実録

（NHK総合 2018年12月23日21:00放映）

皆さんは修行中の身です。設計を厳密に考えるのは勉強になりますが、そこにこだわって何も作れないよりも、とにかく動くプログラムを自力で書けるようになりましょう。

職人の立場から出た言葉

将来情報系の開発に携わる人が目指すべきは：• なんとかできる優秀な職人（プログラマ）• 優秀なプログラマに無視されない設計者・企画者…どちらにもコミュニケーション能力が必要ではある

設計が先か実装が先か

本来は設計が先なのだが…

⚫ 作ってみないと分からないこともある

◆分からないまま設計すると「設計通りには作れない」状況になる。

⚫ ソフトウェア工学で言うプロトタイプやスパイラルという開発過程モデル

◆試作してから本番の設計・実装をする開発方法

◆少しずつ機能拡張していく開発方法

⚫ 「プログラムは二度書け」 2019.04.11

ソフトウェアの開発では、特によくあること

一度目の実装に設計は不要か？

必要。

⚫ 最低限の仕組みを把握することが必要◆とはいえ、作ってみて初めて分かったことによって変更

する可能性がある

…面倒臭がらず、捨てる勇気を持って、設計しなおすことが必要

⚫ 設計は仕組みを 構築／理解 する行為

2019.04.11

ソースコードにおけるプログラムの部品

ソースコード中で、部品であることが分かるように、ひとまとまりのコードとして書く。

ひとまとまりのコード：

⚫ C言語では

◆たとえば関数の定義

◆プログラム全体を複数のファイルに分けることもある

⚫ オブジェクト指向では…

◆クラスの定義

◆（クラス内の）メソッドの定義

2019.04.11

データと手順をまとめたもの

手順。機能を表す。関数みたいなもの

手順。機能を表す

設計できたとする。プログラム全体は部品に分けられる。

いったん、まとめ

大きなプログラムを書くには？

⚫ 部品に分けて考える

◆個々の部品

◆部品を組み合わせる

「では設計してね」と言われても難しい

➡ 部品に分けるときに目安となる考え方は？

2019.04.11

モジュール化という。

これを考えるのが（内部）設計

オブジェクト指向

プログラミングの対象を「モノ」中心に考える

⚫ 「モノ同士の関連づけをプログラムで表現する」という考え方

⚫ 抽象的な概念も、モノとして表すと考えやすくなる

⚫ モノの種類(クラス)と実体(インスタンス)を意識する

◆「手順」は？

◼モノの種類を限定して、それに関連する手順だけを考える

2019.04.11

class instance

Objectオブジェクト

モノを基準にモジュール化する

ということ

クラス・インスタンス・メソッド

⚫ モノの性質や機能はモノの種類ごとに決まる◆クラス（モノの種類）を定義することがプログラミング

◆二種類の部品

◼そのモノを構成する部品であるモノ

◼そのモノに関する手順の部品である手順

⚫ インスタンスの部品◆他のインスタンス

◼モノ（インスタンス）は、そのモノを表す変数やフィールドで表現される

⚫ メソッドの部品◆部品であるメソッドの呼出し 2019.04.11

プログラミング言語 Java

⚫ コンパイルを要する

→機械語ではなく、byte code になる

（Java のクラスファイルと呼ぶ）

⚫ byte code インタプリタで実行する

→OSやCPUが違ってもコンパイル後のファイルが実行できる

⚫ オブジェクト指向をサポートしている

→オブジェクト指向のためのキーワードがたくさんある

2019.04.11キーワードを書かなければならないので、ちょっと面倒

Java ソースファイルの書き方

2019.04.11

⚫ .java のファイルにはクラスの定義を書く。

◆一つのファイル中に複数のクラスの定義を書けるが、public class は一つだけ。

◼ public な class の名前とファイル名を同じにする仕様。

◆ public なクラスは他の .java ファイルから使うことができる… クラスごとに1つのファイルにすることが推奨される

⚫ クラス定義の中身として、フィールドやメソッドを定義する。

◆フィールドは変数のようなもの・メソッドは関数のようなもの

◆ public なフィールドやメソッドは、他クラスから参照できる

◆ static なフィールドやメソッドは、インスタンスが異なってもクラスが同じなら共通（クラス変数・クラスメソッドという）

⚫ 実行時にはクラスを指定する。そのクラスで定義されているmainメソッドが実行の起点

◆ main はクラスメソッドで、文字列の配列を受け取り、返戻値なし

Javaのソースファイル（概略）

public class XXX {

…

}

class YYY {

…

}

class ZZZ {

…

}

2019.04.11

XXX.java

クラスの定義が並ぶ。class はクラスを定義するためのキーワード

public class の名前とファイル名（の末尾の .java を除く部分）は同じ

クラスの定義の中身（ここでは「…」と略した）には、以下を書く：• フィールドの宣言• メソッドの宣言次回、解説します。

package や import の宣言が入ることもある

C言語とJava

⚫ どちらも手続き型の言語で、文法がまぁまぁ似ている

◆混乱しやすいので要注意

◆ Cの関数とJavaのメソッドでは、どちらも{…}（ブロック）の中の命令が順番に実行される

◆変数や代入、四則演算の書き方は同じ

◼ int, double などの基本型がある

◼ Javaではクラスを型として使うことができる

◆ if文, for文, while文の書き方もほぼ同じ

◼ Javaは型に厳格なので、条件は boolean型でなければならない

⚫ C言語の関数と Java のメソッドが対応する

◆仮引数の書き方や return文で返戻値を返すことなどはよく似ている

2019.04.11

次回予告

⚫クラス

⚫インスタンス

⚫メソッド

⚫コンストラクタ

2019.04.11