クラス

オブジェクト指向プログラミングでは「クラス」の事を、物の「設計図」と説明する事がよくあります。これは、現実世界では物を作るときには設計図を元にして作る、設計図があればいくらでも同じ物を作ることが出来る、という事がクラスとオブジェクト(個々の実体に着目すればインスタンスと呼びます)の関係に類似しているための比喩です。

そして、クラスは「属性(フィールドとして定義)」と「操作(メソッドとして定義)」を持つ…　といった説明が続きます。

が、ちょっとこの説明では何もない所から設計図が生まれるような、設計図はどうやって作られるのか、など多少違和感があります。
詳細に入る前にclassという英語の意味を確認してみましょう。辞書にはいろいろな意味が書かれていますが、動詞では「～を分類する」、名詞では「部類」「種類」など、そして数学用語として「集合」という意味もあります。つまり、classは同じ「種類」の「集合」を「分類」したものです。(社会の)「階級」という意味のクラスはまさにこれですね。
この事から、「クラス」はたくさんの中から類似したものを集め、概念化した物と考えられます。

ソフトウェア開発は現実の課題解決をプログラム化しますから、現実が先にあります。オブジェクト指向プログラミングでは、現実を分析してその中で類似するものがあれば概念化(共通性の抽出)してクラスを作り、それを最適化して課題を解決したり改善します。

例えば、チケット販売システムを考えてみましょう。

チケット販売システムの一番重要な役割はチケットの販売ですから、その役割だけに着目するとチケット販売システムは属性として

–

チケットの価格

–

チケットの販売枚数

–

チケットの保有枚数

–

チケットの座席番号

機能、振舞いとして、

–

チケットを販売する

を持ちます。
これをクラス図で表すと左図のように表すことが出来ます。

ところで、チケットにはA席も、B席も、S席だってある。それらについても扱わなければと心配になった人もいるでしょう。
しかし、安心してください。オブジェクト指向プログラミングにはクラスの「継承」という特徴があります。
チケット販売クラスを継承してA席チケット販売システムも、B 席チケット販売システムも、S席チケット販売システムだって瞬時に作れます。
この継承関係をクラス図で表すと左のようになります。

クラスの書式

class クラス名 {
フィールド定義　　　　　　　　型　属性;
　　⠇
インスタンスイニシャライザ　　{ … }
メソッド定義　　　　　　　　　型メソッド() { … }
　　⠇
}

「クラス」をclassとして説明しましたが、オブジェクト指向プログラミングのイメージは持てたでしょうか。

本章ではクラスを構成する技術要素を順に説明します。