プログラミング脳で物事を整理整頓できるオブジェクト指向とは?

プログラミング脳で物事を整理整頓できるオブジェクト指向とは?

本のまとめ

▼読んだ本は?
■オブジェクト指向でなぜつくるのか 第2版
■平澤 章さん
http://amzn.asia/d/c6L3pNr
▼プログラムの歴史って?
【1】機械語
└意味を持たない数字とアルファベットのみから構成され、コンピュータが理解できる言語

【2】アセンブリ言語
└「ADD」「MOV」など英語のような表現を一部だけ取り入れた言語

【3】高級言語
└「z=x+y」など計算式なども表現できるようになった言語
└「FORTRAN」「COBOL」などの言語が有名

【4】構造化プログラミング
└「順次」「分岐(if/case文)」「繰り返し(while/for文)」の3つの処理フローで書かれる言語
└「ALGOL」「Pascal」「C」などの言語が有名
└「メソッド」と「ローカル変数」からなる言語

【5】オブジェクト指向言語
└「クラス」「継承」「ポリモーフィズム」を備えた言語
└日本語に訳すと「モノ指向」「もの中心」
└英語で「Object Oriented Programming language」(OOP)と呼ばれる
└「Java」「Ruby」「Objective-C」「C++」などの言語が有名

▼オブジェクト指向を実現するためのいろんな仕組みは?
■クラス
└変数とメソッドをひとまとめにして一つのファイル化する仕組み

■ポリモーフィズム(多態性)
└各メソッドを「呼び出す側」に共通のものを使えるようにする仕組み
└実際の処理の中身は違っても「呼び出される側のメソッド」を同じ構成にしてまとめておき、一気に呼び出せるようにすることを「メソッドテーブル」と呼ぶ
└ポリモーフィズムではよくこの「メソッドテーブル」が使われる

■継承
└複数のクラスの中で共通して使う部分を別クラスにまとめる仕組み
└共通化された大本のクラスを「スーパークラス」と呼ぶ
└そのスーパークラスを引き継いで使われるクラスを「サブクラス」と呼ぶ

■インスタンス
└確保された動的メモリ領域に変数やメソッドをまとめて格納する仕組み

■パッケージ
└ファイルを格納するための「ディレクトリ(フォルダ)」のような仕組み
└それぞれのプログラムファイルに「階層構造」を付与できる

■例外
└ネットワーク通信障害、ディスクのアクセス障害など予期せぬ状況が起きた時の処理メソッドを、予め決めておける仕組み

■ガベージコレクション
└他クラスから呼び出されなくなり、不要になったインスタンス用の動的メモリ領域を自動的に開放する仕組み

▼コンピュータ上でプログラムを実行する方法は?
■コンパイラ方式
└プログラムに書かれた命令を、コンピュータが理解できる機械語に変換してから実行する方法
└メリットとして、実行時のスピードが速い
└デメリットとして、プログラムを書いてもすぐには実行できず、エラーがなくなるまで修正してからしか動かせない
└銀行システムなど決まったマシン環境のみで動かし、かつ高い処理能力が求められるときに使われる

■インタプリタ方式
└プログラムに書かれた命令を、その場で逐次解釈しながら実行する方法
└メリットとして、コンパイルすることなく手軽に実行でき、プラットフォームが違っても良い
└デメリットとして、実行時のスピードが遅い

■中間コード方式
└まず、コンパイラを使って、特定のマシン環境に依存しない「中間コード」に変換する
└その後、中間コード専用のインタプリタによって実行する方法
└メリットとして、特定の環境に依存しない
└デメリットとして、中間コードを機械語に変換してインタプリタに読み込ませる「仮想マシン」が別途必要になる

▼プログラムのメモリ領域って?
■静的領域
└プログラム開始時に確保され、プログラム完了までずっと確保されるメモリ領域
└プログラムのソースコード情報そのものが格納

■ヒープ領域
└プログラムの実行時に動的に確保されるメモリ領域
└生成されたインスタンスなどがここに格納される
└インスタンスまるごと格納するわけではなく、実際にはメモリ領域の「番地(ポインタ)」を格納しているだけ

■スタック領域
└メソッド実行のための「引数/変数/戻り値」などを格納するメモリ領域

▼クラスの集まりを示す言葉にはどんなものがある?
■クラスライブラリ
└便利な機能を持った部品クラスをまとめたもの
└「文字列操作/計算/日付計算/ファイルアクセス/データベース処理」など、さまざまなことができるライブラリがある

■フレームワーク
└「ライブラリ」自体に特定の目的や役割を持たせ、アプリケーションのように動かせる部品クラスの集まり
└WEBページを簡単に作れるフレームワーク「Applet」なども一時期有名になった

■デザインパターン
└さまざまなソフトウェアに繰り返し現れるクラスの構造に名前を付けて、パターン化したもの

▼UMLとは?
■Unified Modeling Language(統一モデリング言語)の略
■形のないソフトウェアの機能や内部構造を図式(ダイヤグラム)で表現する時の統一規格
▼UMLでソフトウェアの「プログラムそのもの」を表現できる図は??
【1】クラス図
└各クラスファイル、クラス間の継承関係、クラスからのインスタンスの参照関係を描く
└メソッド呼び出しなどプログラムの動きではなく、クラス間の関係性など静的な状態を表現できる
└現実世界に例えると「書籍→本→小説→ノンフィクション」などの順番にカテゴライズして表現していく感じ

【2】シーケンス図
└シーケンスとは「連続」「順序」を意味する英語
└インスタンスを生み出して、その結果実行されるメソッド名と引数を、時間軸を持った順番に沿って表現する
└メソッド呼び出しを含め、プログラム内部の動き方を表現できる
└現実世界に例えると「1.借りたい本を探す→2.本を買う→3.本を読む→4.本を売る」などの時系列で動作を表現していく感じ

【3】コミュニケーション図
└インスタンスを生み出して、その結果実行されるメソッド名と引数を、時系列や順番を考慮せず全体構造のみとして表現する
└メソッド呼び出しを含め、プログラム内部の動き方を表現できる
└現実世界に例えると、本屋でできる行動を全部書きだすと「本を探す+本を買う+本を読む+本を売る」などで表現していく感じ

▼UMLでソフトウェアを実際に使う「人の行動」を表現できる図は?
【1】ユースケース図
└各ユーザーや管理者が具体的にソフトウェア上で何をできるかを表現する
└例えば「ユーザーができること=本を検索する+本を買う」「管理者ができること=本を検索する+1日の売上を集計する」など

【2】アクティビティ図(フローチャート)
└各ユーザーや管理者が具体的にソフトウェア上で何ができるかを時系列で表現する
└例えば「1.ユーザーが本を検索+2.欲しい本をカートに入れて買う」「3.管理者が売れ筋状況を確認+4.追加発注を依頼」など

▼ソフトウェアを作っていく時の3ステップとは?
【1】業務分析
└現実世界の仕事が、どのような役割分担、かつどんなステップで行われているかを確認する
└アクティビティ図(フローチャート)で表現することが多い

【2】要求定義
└現実世界の業務の中で、ソフトウェアにどの範囲まで任せるか(=どこまで作りたいか)を確定する
└ユースケース図で表現することが多い

【3】設計
└採用するソフトウェアとハードウェア製品を何とするかを決める
└ソフトウェア全体を複数のサブシステム等に分割して、全体構造を決める
└個々の部品(クラス)を設計する

思ったこと

プログラムの歴史を紐解いていく中で、どのような経緯でオブジェクト指向が生まれてきたのか、そしてオブジェクト指向を実現するためのクラス、ポリモーフィズム、継承という3つの仕組み、最後にそれらを目に見える図で表現するためのUMLまでが一気通貫でまとめられていました。

オブジェクト指向は現実世界を表現できるという一般的な言い方に対して「いやいやさすがにそこまでは無理」ということを明確に示した上で、オブジェクト指向はあくまでプログラムをする上で整理整頓をして、無駄な処理や変数を発生させないためには、ベストな考え方だぜと書かれています。

でも、そんなプログラミングを効率化するために生まれたオブジェクト指向に関して、そのすべてではなく考え方の一部が、ソフトウェアはじめ何かしらものづくりをする上でとっても役にたち、更にはUMLの図を利用することで、現実世界の物事をみんなに伝わりやすいように整理して表現できるというのは、オブジェクト指向というプログラミングのために生まれた概念の一部が、現実の世界に逆に侵食してきているのかもしれません。

あーいままで時々何言ってるか全然わかんないなと不思議に感じたエンジニアの人たちは、こんなふうに物事を考えてたのかと思うと、ほんのわずか、人の頭の中が垣間見えた気もします。

ありがとうございました!

関連する記事