オブジェクト指向
メインページ > 工学 > 情報技術 > プログラミング > オブジェクト指向
オブジェクト指向(Object-oriented)は、多義的多態的な事物を表すための手法ですが、「オブジェクト指向」という言葉自体も適用される対象によって多義的多態的です。
- オブジェクト指向言語(W:オブジェクト指向プログラミング#OOP言語, Object-oriented programming|Object-oriented programming languages)
- オブジェクト指向プログラミング(W:オブジェクト指向プログラミング, Object-oriented programming)
- オブジェクト指向分析設計(W:オブジェクト指向分析設計, Object-oriented analysis and design)
- オブジェクト指向開発方法論(Object-oriented methodology)
- オブジェクト指向ユーザーインターフェース(W:オブジェクト指向ユーザーインターフェース, Object-oriented user interface)
- オブジェクト指向オペレーティング・システム(Object-oriented operating system)
オブジェクト指向[編集]
オブジェクト指向は、現代のソフトウェア開発において広く採用されているパラダイムです。 オブジェクト指向の基本的な概念には、クラス、オブジェクト、カプセル化、継承、ポリモーフィズムなどが含まれます。 オブジェクト指向は、プログラムの再利用性、拡張性、保守性を高めるための手法として、現在広く用いられています。
クラス[編集]
クラスとは、オブジェクトの設計図となるものです。クラスは、オブジェクトの持つ属性（データ）と振る舞い（メソッド）を定義します。例えば、人間のクラスは、人間が持つ属性（身長、体重、年齢など）と振る舞い（歩く、話す、食べるなど）を定義します。クラスは、同じ属性と振る舞いを持つ複数のオブジェクトを作成するための設計図となります。
クラスは、オブジェクト指向プログラミングにおいて非常に重要な役割を果たしています。クラスを使うことで、プログラマは複雑なシステムを効率的かつ簡潔に記述できます。
オブジェクト[編集]
オブジェクトは、クラスを元に作成された実体です。クラスが設計図であるならば、オブジェクトは設計図に基づいて作られた製品のようなものです。例えば、人間のクラスから作られたオブジェクトは、実際に存在する人間のように振る舞います。オブジェクトは、それぞれが独自の状態を持ちます。これをオブジェクトの状態と呼びます。オブジェクトは、クラスが定義するメソッドを呼び出すことで振る舞いをします。オブジェクトの状態が変化することで、オブジェクトが振る舞いを変えることもあります。
オブジェクト指向プログラミングでは、プログラマがオブジェクトの状態や振る舞いを直接操作することはありません。代わりに、オブジェクトが公開するメソッドを呼び出すことで、オブジェクトの状態や振る舞いを操作します。このアプローチは、プログラムの柔軟性や再利用性を高めることができます。
カプセル化[編集]
オブジェクト指向では、カプセル化という概念が重要です。カプセル化とは、オブジェクトが自身のデータとメソッドを隠蔽することで、他のオブジェクトからの不正なアクセスを防止することです。
カプセル化により、オブジェクトの内部実装が隠蔽されるため、外部からのアクセスを制限することができます。これにより、オブジェクトの安全性が高まり、プログラム全体の信頼性が向上します。
継承[編集]
継承は、既存のクラスを拡張して新しいクラスを作成する方法です。新しいクラスは、既存のクラスのすべての属性とメソッドを継承します。 これにより、新しいクラスは既存のクラスと同じような振る舞いをすることができます。 継承は、コードの再利用性を高めることができます。また、継承を使うことで、コードの修正や保守も容易になります。
ポリモーフィズム[編集]
ポリモーフィズムとは、同じメソッド名を持つ複数のクラスやオブジェクトが、異なる振る舞いをすることができることを指します。具体的には、オブジェクト指向プログラミングでは、同じ名前のメソッドを異なるクラスで定義することができます。
例えば、異なる形状を表すクラス（円や四角形など）があり、それぞれが「面積を計算する」というメソッドを持っている場合、ポリモーフィズムにより、同じ「面積を計算する」というメソッドを呼び出すことができます。ただし、呼び出されるメソッドは、それぞれのクラスで定義されたものが呼び出されます。
ポリモーフィズムにより、プログラムの柔軟性が向上します。新しいクラスを作成する際に、既存のクラスと同じメソッド名を使うことができ、プログラムの読みやすさや保守性を高めることができます。
オブジェクト指向は、プログラムをより柔軟かつ効率的に設計するための手法です。クラスとオブジェクトを用いることで、プログラムの再利用性、拡張性、保守性が向上し、プログラムの信頼性を高めることができます。カプセル化、継承、ポリモーフィズムなど、オブジェクト指向には様々な概念がありますが、これらを理解し、適切に活用することが、より高品質なプログラムの作成につながります。
コード再利用の手法としての「オブジェクト指向」[編集]
オブジェクト指向プログラミングは、コード再利用のための効果的な手法の1つです。オブジェクト指向プログラミングでは、コードを再利用するためにクラスとオブジェクトを使用します。クラスは、オブジェクトを生成するための設計図であり、オブジェクトは、クラスに基づいて生成された実際のインスタンスです。
オブジェクト指向プログラミングの主な利点の1つは、コードの再利用性が高いことです。クラスは再利用可能であり、複数のプログラムで使用できます。また、同じクラスから複数のオブジェクトを作成できるため、同じコードを複数回書く必要がありません。これにより、開発時間とコストが削減され、開発プロセスが迅速化されます。
オブジェクト指向プログラミングには、以下のような他の利点もあります。
- 再利用性が高いため、開発時間が短縮される。
- コードの保守性が向上し、バグの発生率が低くなる。
- コードの拡張性が向上し、新しい機能の追加が容易になる。
- プログラムの分割が容易になり、複雑な問題を解決するためのソフトウェアの設計が容易になる。
ただし、オブジェクト指向プログラミングを実装するには、十分な時間とスキルが必要です。また、適切な設計とコーディングを行わない場合、コードの再利用性が低下し、プログラムの複雑さが増す可能性があります。
したがって、オブジェクト指向プログラミングを実装する場合は、適切な設計とコーディングを行う必要があります。そのためには、設計パターンやコーディング規約などのベストプラクティスを学び、実践することが重要です。
コードの共有[編集]
インターネットの発達した現在において、再利用を実現するために重要なことは、言語の仕様よりも、
アプリ開発者がなるべくコードを公開したりして設計書・仕様書も用意しておくとか、
開発者が自身のノウハウの一部を公開するとか、 そういう姿勢だと言えるでしょう。
極端な例を言えば、開発者がアプリケーション・プログラムのコードを無料で公開すれば、ほかの開発者は似たアプリを作りたい場合に、いちいちゼロからコードをプログラミングをしなくても、コード公開されたアプリを組み合わせたり、公開コードの一部だけを書き換えれば済みます。
なお、仕様書はけっして形式的に存在するだけでは駄目であって、他人が読んでもコードの仕組みが分かるように、必要な情報をそろえておく必要があります。(ネット上では「操作説明書」と「仕様書」を勘違いしている人も多く、コードの仕組みを説明せずに操作方法だけかいてある仕様書が多い。しかし、コードの共有が目的なら、コードの仕組みを優先して紹介する書類こそが真っ先に必要である。そういう事情もわからずに、形式的に書類を用意する人が多い
1950年代くらい「オブジェクト指向」の用語が(おそらく)提案された時代はまだインターネットの機能が貧弱だったので、やはり用語の意味が、現在のアプリ開発の実態にあっていません。
オペレーティングシステム[編集]
また、過去の勘違いでは、オペレーティングシステムの存在を見落としていると言っても過言ではないかもしれません。つまり、
1990 - 2010年代の実際のコンピュータ産業の歴史ではどのアプリにも存在するウィンドウ表示などのコード再利用の実装は、実際にはオペレーティングシステムの仕事
でした。
そもそも1995年ごろのウィンドウズやマッキントッシュの当時の宣伝文句は、そういったものでした。
すなわち、当時のよくあった宣伝文句で
- 「 『オペレーティングシステム』という新システムによってどのアプリでも活用する、ファイル管理機能や画像出力機能などの管理の細部を担当するので、アプリ開発者はOSに指令する機能だけを覚えば良くなるため学習負担や開発コストが減って、コスト削減ができます！！」
という感じの宣伝文句でした（マイクロソフトやアップル自身がそう言ってたかは覚えてないが、よく書店のパソコン入門の書籍などで、当時は新型OSがそう説明されていた）。
どの言語で開発するにしても、例えばWindowsアプリならオペレーティングシステムが共通（当然、WindowsアプリのOSは全てWindowsである）しており、それらOSのコードはC言語またはC++に類似の言語で書かれています。
アプリのコードを書く場合にはOSの機能（「システムコール」と言います）を呼び出すコードを書くのですが、必ずしも直接呼び出すとは限りません。オペレーティングシステムが異なる場合、コードの共通化はラッパーライブラリを利用すれば、共通のコードにできます。今どきのアプリケーションは、フリーソフトウエアでもクロスプラットホームは普通のことです。
このように、例え同じC++どうしでMacintosh向けアプリとWindows向けアプリを書いても、そうなってしまうのです。
繰り返しますが、人類で最初に「オブジェクト指向」の用語が提案された時代（恐らく1950年代くらい）は、まだOSの機能が貧弱だったので、あまり用語の意味が現在のアプリ開発の実態にあってません。
他の言語[編集]
C言語でも部品ごとに動作を検証できます。
なぜなら、
- C言語の「関数」を部品として利用すれば済む。
- コードのあるファイルを組み合わせる機能は無印の標準C言語（C++ではなくC）にもある。（「分割コンパイル」とか「ヘッダファイル」とかの機能）
です。
実際にC言語で書かれた大規模なプログラムはたくさんあります。（LinuxのカーネルはC言語です。）
かつて、1990年代ごろまでは「コードの再利用のためには言語の仕様が重要だ！」とか思われてた時代がありました。
GUIプログラミングの要素物を「オブジェクト」という流儀もある[編集]
GUIプログラミングには、ツールキットライブラリを利用したり、ブラウザのウインドウを利用したりします。これらは、オブジェクト指向プログラミングとは何の関係もありませんが、ボタンやら入力欄やらをオブジェクトとして扱うと便利なので、初心者向けのお手本として良く使われますし、これらを使う仕掛けも実際にそうなっています。実際に生成したオブジェクトが、ウインドウ上に現れて目視できるというのも、わかりやすいです。
さて、GUIプログラミングをする時ウィンドウ内の表示対象として、
ボタン（こういうの→ ボタン ） や テキストボックス（こういうの→ ）など、
いろいろな表示対象を選ぶのですが、この表示対象のことを「オブジェクト」とまとめて言う場合があります。
いちいち「ボタンやテキストボックス など」などと言うのが面倒なので、「オブジェクト」というわけです。(なお、マウス操作やキーボード入力などのイベントのこともオブジェクトという場合があるが、本書の理解には不要なので説明を省略する
Windowsを用いた Visual C++ や Visual C# など（まとめて Visual Studio という）をもちいた GUIプログラミングではこのようなウィンドウ部品としての意味での「オブジェクト」という用法が）現状では）避けられません。
たとえば、初期状態では空白表示のテキストボックス（名前は"textBox1"とする）内部に、ボタンを押すと「こんにちは」と文字表示させる機能をつけたい場合には、Visual Studio が自動的につくる
private void button1_Click(object sender, EventArgs e)
{
// ここにテキストを挿入 (編注: このコメントは生成されない。）
}
というカッコの中に、
プログラマーは手動で、
private void button1_Click(object sender, EventArgs e)
{
textBox1.Text = "こんにちは";
}
となるようにtextBox1.Text = "こんにちは";と、コードを記述します。
なお、
private void button1_Click(object sender, EventArgs e)
{
}
の部分はプログラマーがマウス操作でボタンをつくったときにVisual Studio が自動的につくる部分なので、この部分を手作業で入力することはありません。
上記のコードでいうtextBox1の部分がオブジェクトです。ドット（.）のあとについている「Text」の部分は一般にプロパティと言います。
つまり書式は、「オブジェクト.プロパティ」という書式になります。
テキストボックスには、表示文字のほかにもプロパティがあり、ボックスの大きさとか、ボックスの背景色とか、表示文字のフォントやフォントサイズとか、表示文というプロパティの他にも様々なプロパティがあるので、どのプロパティなのかを区別するために、「textBox1.Text」のようにオブジェクト名とプロパティ名とを併記する必要があるのです。
このような、ウィンドウにあるテキストボックスやボタンなどの部品としての用法の「オブジェクト」が、GUIプログラミングで一般的に使われる「オブジェクト」という意味です。
GUIにかぎらない「オブジェクト」とは[編集]
たとえば、「170.0」という数値データだけでは意図が不明ですが、しかし、たとえばあらかじめ仕様書などで「このプログラムはウイキ高校での身体測定の結果を処理するプログラムです。」という情報がったとして、さらにコードで「yamada.sintyou=170」と書けば、意図が、ヤマダ（山田？）氏の身長だと、ハッキリ分かります。
現代では、「オブジェクト」とは、このような記法における、「yamada」の部分のことだけです。
「sintyou」にあたる部分は、アトリビュート（「属性」の意味）とかメンバとかプロパティ（「特性」や「属性」の意味）などといいます。つまり、オブジェクトが持っているデータの定義のことが、アトリビュート（またはプロパティまたはメンバ）です。
また、ヤマダ氏に歩いてもらう処理は（例えばCGソフトなどで、ヤマダ氏の形をしたキャラクターが歩行するとか。）、「yamada.aruki()」などとコードを書けば、同業プログラマーにコードの意図が伝わりやすくなります。
この「yamada.aruki()」というコードの場合、オブジェクトはyamadaヤマダだけです。「aruki()」にあたる部分はメソッド（「方法」という意味）といいます。
もし、ヤマダさんではなく、ロボット1号くん（オブジェクト名は「roboiti」としよう）に歩いてもらうことをオブジェクトの記法で表現するなら、「roboiti.aruki()」というコードになります。
そして、このようなコードでは、「yamada.」の部分が、再利用できます。
もしヤマダ以外に、サトウなどの新しい人員が加わっても、オブジェクトの部分を「satou.」などに変えて、コードを再利用すれば、済むような仕組みになっています。
「satou.aruki()」で、サトウさんの歩きをオブジェクトの記法で表現したことになります。
この場合、satouもオブジェクトです。
「オブジェクト」の定義は人によってバラバラ[編集]
「オブジェクト指向」という言葉そのものはコンピュータの黎明期からあったようですが、しかし広く言われ始めたのが1990年代ごろからなので、この時代のWindows95やマッキントッシュ用OSなどのOSの特徴（GUI指向、マルチスレッド作業に対応など）を指して「オブジェクト指向」とか言う人もいます。しかし、特にパソコン業界では「オブジェクト指向」とは何かの決まりはありません。
単に、90年代のOSを「オブジェクト指向」という人もいる、そういう人もいるってだけです。
90年代後半ごろにC++というプログラミング言語が流行り始めたり、あるいは、Visual Basicなどのwindows用プログラミング言語が流行り始めたこともあり、これらの90年代後半ごろに流行しはじめたプログラミング言語のことを「オブジェクト指向」と言ったりする人もいます。
ですが、やはりパソコン業界では結局、「オブジェクト指向」とは何かの決まりはありません。
「オブジェクト指向」対応のプログラミング言語はなくてもプログラミングできる[編集]
1990年代の後半ごろから、「オブジェクト指向」に対応したプログラミング言語（C++など）が登場し始めました。
1990年代後半の当初、これからは「オブジェクト指向」を活用したプログラミングが主流になると考えられましたが、しかし10数年ほどたても、実際には、「オブジェクト指向」とやらの概念は主流になりませんでした。
そのため、かつて1995年 - 2005年頃は、書店のパソコン書籍コーナーに「オブジェクト指向」を説明した理工書などが多くありましたが、2010年代後半以降の現代では、あまり見かけなくなりました。
なので、このページを読んでる読者は、あまり深く「オブジェクト指向」とやらの意味を考える必要がありません。そのような論説（「オブジェクト指向の言葉の意味を探求すべき」というような論説）は、市場淘汰されました。
「オブジェクト指向」の細かい定義は、人によって、バラバラです。あまり、定義にこだわる必要もありません。
C++（シープラスプラス）などの1990年代後半あたりから普及し始めたプログラミング言語に見られる文法（「クラス」機能など）の特徴を説明するのに、「オブジェクト指向」という用語が使われることがあります。
この1995 - 2005年頃の消費者は「きっと、これから、プログラミングに、クラスの概念が必要・ほぼ必須になるだろう」と予想していましたが、しかし現状では、「クラス」機能を使わなくても高度なプログラムができます。
じっさい、C言語には「クラス」機能がないし、C言語で書かれた高度なプログラムは多くあります。リナックスOSの「カーネル」（OSの中核部分）はC言語で書かれています（C++では、カーネルは書かれていません）。
また、他のプログラミング言語でも、クラス機能のある言語でも、多くの実用的なプログラムが、クラス機能を使わなくても書かれています。
そして、このC++ですら、1980年代に登場しはじめた当初は「きっと、それまで普及していたC言語に代わって、これから普及していくだろう」と期待されていましたが、しかし2010年代の現代でも、相変わらず、C++よりもC言語のほうが主流です。
「オブジェクト指向」の流行の以前には「構造化」があった[編集]
そもそも、1990年代バージョンのオブジェクト指向よりも前に、1970 - 80年代には「構造化プログラミング」という考えがありました。
構造化プログラミングに基づいたプログラミング言語のほうが、C言語などとして、先に（構造化プログラミングにもとづく言語が）実装され、普及しました。
構造化プログラミングは、例えば、「（処理手順を含まない）データは、データどうしで、まとめる」、「（処理手順を含まない）データが何種類もある場合、関連性のあるデータどうしで分類する」、「処理は、処理どうしで、まとめる」（そのため）「処理とデータとは、区別する」、などのような考えかたです。
処理手順の妥当性を吟味するのは大変ですから、なるべく、処理手順を考えなくても作業できるようにする必要があり、そのため、処理手順についてのコード内容と、処理手順をのぞいたデータとを、別々のグループにまとめる、という設計手法があります。
とはいえ、全く処理手順と、データとが、完全に切り離されいたら、そもそもアクセスできないので、プログラム実行の最初と最後だけで、データと処理手順とを連動させたりしますが・・・。
ともかく、同じ種類のデータをまとめる「構造体」（こうぞうたい、structure）という機能が考えられ、実用化されました。
また、そのプログラムの処理手順を、さらに複数の小さな処理手順（「サブルーチン」「モジュール」）に分解することにより、「プログラムは、サブルーチンの組み合わせである」とする機能も、実用化されました。
なお、C言語などでいう、処理をまとめたもののことを「関数」（function）というのは、このサブルーチンのようなものの事です。もっともサブ（副、予備）があるならメイン（主）があるわけで、C言語では、最初に実行する特別なルーチンの事を「メイン関数」と呼んでいます。
なお、コンピュータで三角関数などの数学的な意味の関数を扱う場合は、例えば「数学関数」などと呼んで、サブルーチンとしての「関数」の用法との混同をふせぐ場合もあります。
この「構造体」でまとめられるデータとは、C言語などの場合、変数データです。処理手順（「関数」）などは、C言語の「構造体」では、まとめられません。
本来、「構造化プログラミング」の考え方では、関数（処理手順）をさらにまとめて構造化してもかまわないハズでしょうが、しかし、C言語はそうなっていません。そのため、後述する「オブジェクト指向」にもとづいた（C言語よりも）新しいプログラミング言語で、関数を含めてまとめて構造化する機能が追加されるように、なりました。（後述する「オブジェクト指向」にもとづく言語では、「クラス」という機能を用いて、変数データも関数も、まとめる事ができます。）
さて、ともかく、上述のような構造化プログラミングの利点として、まず、企業などでプログラマーが集団で作業している際に、コード内容が、理解しやすくなります。なぜなら、プログラマーがデータを調整するときは、プログラマーは、データの書かれたコードだけを見れば、済むからです。
そして、このように構造化をして分かりやすくすることによって、もしバグが発生しても、構造が分かりやすいので、バグの箇所も特定しやすく、そのため、修正しやすいという事へと、つながっていきます。
さらに、分業も、しやすくなります。
プログラミング言語である「C言語」そのものの開発では、構造化プログラミングの考えかたも取り入れて、C言語の仕様が決められました。
しかし、構造化プログラミングをすすめているうちに、単にC言語の機能を利用だけでは、まだまだ、構造化が不十分だという事が、分かってきました。
それこそC言語は、複数の種類の変数データを「構造体」として、まとめる事ができるくせに、しかし一方で、複数の種類の関数をまとめる機能すら、C言語には、ありませんでした。
もちろん、個々のソフトウェア会社が、関数をまとめるための関数をコードに記述することで、当面の対応はできます。しかし、個々の企業が自分たちで独自の構造化を行っていては、他社と共同作業を行うのに支障がありますし、大学などの学校教育でも個別の企業の方法については教育できませんし、そのため、ソフトウェア生産の効率が下がってしまいます。
そして、さらに新しいプログラミング手法が提案され、結果的に、（次の節で示しますが）「オブジェクト指向」などとして、新手法が、ひとまとめに呼ばれていきます。
しかし、もしかしたら実態は「C言語が不便なので、新しい言語を考えよう」という側面も、『オブジェクト指向』というフレーズには、あったかもしれません。
こういう実態もあるため、本来なら「構造化」として分類されるべき手法であっても、「オブジェクト指向」に分類されてしまっている手法もあります。
たとえば、（C＋＋言語にある）「複数の関数（処理手順）どうしをまとめる機能」なんて、なんで『構造化』に分類されずに『オブジェクト指向』に分類されるのか、後世の人間には、いまいち分かりません。
なので、あまり、「オブジェクト指向」の厳密な定義にこだわる必要もありません。
クラスの構成要素としての「オブジェクト」[編集]
「クラス」とは、何なのかというと、言語によって意味が微妙に異なりますが、とりあえず この節で説明する意味では、
- 「クラス」とは、C言語にあった構造体という機能を拡張した新機能（1980年ごろの登場当時）だったもの
です。
具体的にどう拡張しているのかは、プログラミング言語ごとによって微妙に異なるので、覚える必要がありません。
いちおう、C++のクラスには、C言語の構造体には無い新機能もありますが、しかし、ほとんどの初心者プログラマーのクラスの使い方は、構造体と似たようなものになるでしょう。
「オブジェクト指向」の定義は人によって、バラバラです。クラスの定義も、プログラミング言語によって細部の意味がバラバラです。あまり、定義にこだわる必要もありません。
よくある「オブジェクト指向」の定義の例として、たとえば、
「型から実体を作る」
というのがあります。
「クラス」と呼ばれる「設計図」から、実体物に対応するデータを作ろう、とする理念です。
この「実体のデータ」（※ 実体の特性を反映したいデータ）は、一般的には「オブジェクト」や、「インスタンス」と呼ばれています。
ですが、構造体プログラミングの産物である構造体が、とっくの昔から、「構造体」という設計図のようなものと、「構造体変数」というデータとの分離を、実現しています。
そして、C++の「クラス」は、単に構造体を拡張したものにすぎないので、C++のクラスに関するかぎり、実はオブジェクト指向で提唱された新理念は、あまり実装的には新しくなかったのが実態です。
このように、プログラミング言語にある「クラス」機能は、あまり名前と内容が、一致していません。なので学習者は、あまり正確な理念内容には、こだわらないほうが、得策でしょう。
「クラス」と聞くと、なんとなく、階層的な分類を思い浮かべるでしょう。しかし、「クラス」をもちいずに、従来の「構造体」でも、階層的な分類は、可能です。結局、データをまとめようとした時点で、個々のデータと、そのデータの集まりとしてのグループという、階層が出来上がってしまいます。
さて、もし、あるデータに、将来的に実体の特性を反映させたい場合、いちばん手軽な方法として、そのデータがなんのためのデータなのかを、コード中で定義してしまう事です。
たとえば、「170.0」という数値データだけでは意図が不明ですが、しかし、たとえばコードで「yamada.sintyou=170」と書けば、意図が、ヤマダ（山田？）氏の身長だと、ハッキリ分かります。もっとも、このような記述は、クラス機能を使わなくても、「構造体」でも可能です。そもそも、このような記法は、もともと、C言語などで構造体を定義するときの記法です。
このため、「そもそもクラス機能は不要では？」とか「構造体の亜流では？」などと考える人たちもいて、その人たちは、C++ではなく（クラス機能のない）C言語でプログラムをしたりするわけです。
さて、「クラス」機能の用語では、この「yamada.sintyou」というコードの場合、オブジェクトはyamadaヤマダだけです。「sintyou」にあたる部分は、アトリビュート（「属性」の意味）とかメンバとかプロパティ（「特性」や「属性」の意味）などといいます。つまり、オブジェクトが持っているデータの定義のことが、アトリビュート（またはプロパティまたはメンバ）です。
また、ヤマダ氏に歩いてもらう処理は（例えばCGなどで、ヤマダ氏の形をした模型が歩行するとか。あるいはヤマダがロボットなら、ロボット歩行のコードになる）、「yamada.aruki()」などとコードを書けば、同業プログラマーにコードの意図が伝わりやすくなります。
この「yamada.aruki()」というコードの場合、オブジェクトはyamadaヤマダだけです。「aruki()」にあたる部分はメソッド（「方法」という意味）といいます。
そして、このようなコードでは、「yamada.」の部分が、再利用できます。
もしヤマダ以外に、サトウなどの新しい人員が加わっても、オブジェクトの部分を「satou.」などに変えて、コードを再利用すれば、済むような仕組みになっています。
もっとも、このような記法（yamada.sintyou）は、けっして「クラス」機能に特有ではありません。「構造体」の時代からある記法です。
結局、用語が統一されていません。そもそも、「オブジェクト指向」時代以前からすでに用語がおかしく、構造化プログラミング時代の「構造体」という用語がオカシイです。英語の日常語でいうstructure（構造）とは、C言語のstrucureは、まったく意味が違います。
もし、変数などのデータをまとめる機能（いまでいう「構造体」）に日常語と似た名前をつけるなら、「グループ」とか名付けるべきだったのでしょう。
結局、そもそも「構造体」という用語そのものが、1960年代ごろのIT業界内部での流行語だった「構造化プログラミング」という用語をもとにつくっただけの、目先の造語でしかありません。1960年ごろに目先の流行語を追って命名しただけのプログラム用語が、2010年代の今だに修正されずに改革されずに続いてるわけです。
このように、プログラムの用語は、発明当時の開発者たちが、あとさき考えずに当時の流行にあわせて用語を命名してたりして、その命名のまま放置されています。けっして物理学や数学などのように、用語が修正されたりしません。
なので、あまり、プログラミング用語の深い意味を考えないほうが、私たち利用者としては得策です。
はたして、実際のいくつかのプログラミング言語にある「クラス」と呼ばれる機能が、はたして「オブジェクト指向」とされる理念を実現できてるかどうかの実情はともかくとして、情報科学・情報工学などではプログラミング言語での「クラス」の構成要素は「オブジェクト」などと呼ばれます。
関数すらクラス化するプログラミング言語もある[編集]
C言語などでいう「関数」は、手続きをまとめたものです。
さて、オラクル社のJavaや、マイクロソフト社のVisual C++ などのVisual ◯◯やC＃では、手続きをまとめたものを定義するときに、「class」という宣言を使います。これらJavaやC♯では、もしプログラマーが関数を使用したいときに「class」という構文をつかわないと、そもそも関数を宣言できず、関数を使用できません。
それらのプログラミング言語では、どうも、関数すらクラスとして分類しようという方針のようです。
ですが、ほかの多くのプログラミング言語では、採用されてない仕様ですので、分かならくても悩まなくても良いです。
このJavaやVisual ◯◯などの、関数がclassによって定義される仕様の欠点として、簡単な処理を書きたいだけの場合ですらコードが長くなる、という不便な欠陥があります。
たとえば、「Hello」という文章を表示したい場合、 もしJavaなら、
（Javaの場合）
public class クラス名 {
public static void main(String[] args){
System.out.println("Hello");
}
}
という、かなり長い文になります。
マイクロソフト社のVisual ◯◯も、同様に長くなる傾向です。たとえばVisual C♯（シーシャープ）および単なる「C♯」では、
（C♯の場合）
class クラス名
{
static void Main() {
Console.WriteLine("Hello");
}
}
というふうな感じになります。
これらJavaやC♯のプログラミング言語の入門書を読んでも、結局、クラスについて、2度、説明することになります。まず、書籍冒頭での、C言語でいう関数としての機能の「クラス」の説明するほかに、書籍の中盤のほうで、従来のC++でのクラスの機能をもつ別内容の「クラス」について説明するというように、クラスについて2度説明しなおす羽目になります。
なので、関数とクラスとを同一視することは、けっして普遍的な原理ではなくて、いちぶの企業の提供するプログラミング言語の仕様にすぎません。
また、上記のような関数の分類をする文法で、構造体による分類ではなく、クラスを使って分類するという文法にされている理由も、単に歴史的な偶然にすぎないでしょう。単に、マイクロソフト社などの大手の会社が、そのような文法を採用した、というだけの事です。
オブジェクト型[編集]
C＃(シー シャープ)などの いくつかの言語で採用されている「オブジェクト型」という型は、一般的な値型とは考え方が違います。
値型では、
a = 2 b = 3 a = b a = 4
とすると、a = 4、b = 3 になります。しかし、オブジェクト型では、a = 4、b = 4 となります。 こうなる理由は、値型とオブジェクト型の仕組みが違うからです。
値型では、変数自体が値を持っているという考え方をします。
しかし、オブジェクト型の場合は違い、メモリへのポインタという考え方です。
メモリのどこかへオブジェクトが作られ、オブジェクト名というのはリファレンス名であり、メモリを参照しているだけである。
これがオブジェクト型と値型の違いです。これをしっかり把握しておかないと、あとで混乱してしまうことになります。
デジタル家電など[編集]
歴史的な経緯により、Javaという言語が、よくデジタル家電で使われていた時代が2005年くらいまでありました。
また、日本のフィーチャーフォン向けアプリケーションプログラムが、Javaで記述されていた時代もありました。
原理的には、デジタル家電と、Javaなどのクラスや継承・カプセル化などの概念は無関係ですが、しかし歴史的な理由により、Java的な言語によるアプリ開発環境がデジタル家電の界隈では普及していますので、これらの分野に興味ある人にはJavaの学習も必要かもしれません。
スマーフォンの Android OS もアプリ開発言語としては、Java または Kotlin というJava系文法の言語を採用しています。