More than 5 years have passed since last update.

オブジェクト指向でなぜつくるのか第4章 ~補足~

Posted at 2018-12-08

はじめに

「オブジェクト指向でなぜつくるのか-第2版-」の第4章に書かれているオブジェクト指向プログラミングの三大要素をまとめました。今回は、さらに進化した最近のオブジェクト指向プログラミングの仕組みを補足としてまとめます。

プログラム言語によっては、変数を定義するときに型を指定することがあります。これは、プログラマが楽をするための仕組みです。

変数に指定した型以外の値がセットしたり、整数と文字の掛け算など意味的におかしいロジックが書かれたりすると、コンパイル時や実行時に明示的なエラーにすることができます。エラーに気づける仕組みがあることで、プログラマが楽になります。

こうした型宣言・チェックの仕組みは、高級言語や構造化言語のときからありましたが、オブジェクト指向プログラミングでは、さらにクラスまでも型として宣言することができるようになりました。

Javaだと下記のようなサンプルになります。

例

CharacterCounter counter; // 変数counterはCharacterCounter型であることを宣言
counter = 100; // <- コンパイルエラー
counter = new CharacterCounter(); // <- コンパイルOK

自分で作成したクラスまでも変数の型として宣言できるようになったことで、エラーの検出がさらに向上し、プログラマが楽できるようになりました。

パッケージとは「まとめる」仕組みです。しかし、クラスと違ってメソッドやインスタンス変数を定義することはできません。

ファイルディレクトリの構造と同じように、コードを階層構造でまとめることができます。

クラスと同様にコード全体の見通しをよくして、コードを管理しやすくしています。

ここで定義されている例外は、「戻り値とは違う形式で、メソッドから特別なエラーを返す仕組み」のことです。

特別なエラーの例

ネットワークの通信障害、データベースのデッドロックなど

従来のサブルーチンの仕組みでは、エラーコードを使った方法が一般的でした。（1なら通信障害、2ならデッドロックなど）

しかし、エラーコード方式だと以下2つの課題がありました。

課題①: エラーコードの判定処理を確実に行う必要がある
- エラーコードの判定処理を忘れたり、間違えたりすると、障害原因の特定が困難になる
課題②: エラーコード判定の同じようなロジックが複数のサブルーチンで連鎖する
- エラーコードを呼び出し側に返すだけでも、同じような判定ロジックを書かなければならない

そういった課題を解決するために作られたのが、例外という仕組みです。

例外の仕組みでは、特別なエラーを返す可能性があることをメソッドで宣言し、そういったメソッドを呼び出す側では例外を処理するロジックが書かれていないとエラーになります。（ 課題① の解決）

また発生した例外を上位のメソッドに渡すだけのときは、例外を宣言するだけでエラー処理を書かなくてよくなります。（ 課題② の解決）

つまり、例外には 無駄なコードをなくすという効果 と、 処理の書き忘れを防止するという効果 があります。

C言語やC++などの以前のプログラミング言語では、不要になったメモリ領域を削除する処理を明示的に書かなければなりませんでした。

オブジェクト指向プログラミングでは、インスタンスを大量に作成できるがゆえに、不要になったインスタンスを削除してメモリ領域を確保しないと、 メモリリーク が発生してしまいます。

こうした課題を解決するために作られたのが、 ガーベジコレクション という仕組みです。カベージコレクションは、不要になったインスタンスを自動的に削除します。

不要となったインスタンスを削除するというコードを、プログラマが明示的に書かなくてよくなりました。