プログラムの作成：オブジェクト指向か構造化か？
When writing 課題用プログラム を作成する際、プログラムをオブジェクト指向で書くか構造化で書くか、お客様にアドバイスすることがよくあります。もちろんこの場合、最も重要なのは、注文したプログラムが提出される授業で、プログラミングをどのように教わったかです…そのため、本来は、私たちが作成する 課題用プログラム をどのように書くべきか、お客様ご自身がお知らせくださるのが一番です。これは非常に重要なので、必ず確認することをおすすめします。この点で判断を誤ると、単位を落とす結果になりかねません。
ただし、担当の先生がこの点を学生の自由に任せている場合、率直に言って、答えは一言に集約できます。オブジェクト指向です。ですが、まず定義から始めましょう。
構造化プログラミング は、手続き型プログラミングの概念を拡張したもので、 プログラムの作成 において、コードを階層的にモジュールに分割し、厳密に定義されたインターフェースを通じてモジュール同士が通信する方法論です。データ、手続き、関数は互いに直接結びついておらず、命令は順番に実行されます。構造化プログラミングの土台は条件文とループであり、あらゆる種類のジャンプは行儀の悪いものと見なされます。それは線形プログラミングの名残で、ソースコードの読みやすさを損ない、解析を難しくするものと（当然ながら）考えられています。
オブジェクト指向プログラミングは、これに対し、プログラムのデータと振る舞い（手続きと関数で定義され、オブジェクト指向ではメソッドと呼ばれます）を組み合わせたオブジェクトでプログラムを定義する、コンピュータプログラムの作成の方法論です。プログラムは、そうしたオブジェクトの総和として表現され、オブジェクト同士が通信して、プログラムに課されたタスクを実行します。これにより、ソフトウェアの個々の要素を担当する、互いに協力するオブジェクトを組み合わせることで、プログラマーのチームが大規模なプロジェクトを効率よく書けるようになります。
客観的な定義はこのくらいにして、今度は（おそらく完全に主観的な）意見を述べましょう。私の考えでは、 オブジェクト指向プログラミング には一定の規律と制約があり、それがプログラミングという技を志す若者を学習から遠ざけることも多いのですが、オブジェクト指向の原則を知るために少し時間をかければ、間違いなく大きな利点が得られます。
データに対するオブジェクト指向のアプローチと、プログラマーのチーム全体による プログラムの作成 から生まれる可能性は、極めて重要だと思います。現実の世界では互いに面識すらないことの多い人たちが、中身を見る必要もなく、クラスのメソッドのインターフェースの説明だけを頼りにやり取りしながら、巨大なアプリケーションを一緒に作り上げるのです。 オブジェクト指向プログラミング のもう一つの利点は、コードが読みやすく明快なことです。定義ファイルを一目見るだけで、あるクラスやメソッドが何を担当しているのかが、すぐにわかります。
構造化プログラミングでは状況がまったく異なります。まず、大きなアプリケーションで読みやすいコードを実現するのは極めて困難です。次に、一度書いたコードは再利用に向いていません。他の用途に合わせるには、たいてい多くの場所を数多く修正しなければならないからです。そのため、構造化で書かれたプログラムが再利用される可能性は低いといえます。プログラマーにとっては、古いコードをいつまでもいじり回すより、新しいクラスを一から書くほうが、たいてい時間がかかりません。
こうした明白な事実にもかかわらず、大学では 構造化プログラミングを教えることのほうがはるかに多く、学生が提出を求められるのも、そのように書かれた 課題用プログラム です。もちろん、これは情報工学のコースには当てはまりません。そこではオブジェクト指向がすでに標準ですが、情報工学と直接関係のないコースでは、まだ珍しいのが実情です。
この記事を終えるにあたり、私が書いたわずかな言葉が、 オブジェクト指向プログラミングを学ぶきっかけになればと願っています。このテーマを語り尽くしたなどとは思っていません。いくつかの問題に触れただけで、オブジェクト指向プログラミングの利点のほんの一部を述べたにすぎません。具体的な課題に取り組むうちに（特にグループで作業する場合は）、まだたくさんの利点が見つかるでしょう。