なぜ、今さら「オブジェクト指向」を学ぶのか？

はじめに

本連載は、オブジェクト指向、クラス設計やデザインパターンを覚える必要があると感じている新人や若手エンジニアに一から分かりやすく学んでもらうことを目的としています。

また、新人や若手でなくても、これから勉強しよう、以前に勉強途中で理解できず諦めてしまったという中堅エンジニアでも、挫折することなく実務で活かせるまでに理解できるような指南書となれば幸いです。

本連載の開始に至った背景

オブジェクト指向、クラス設計、デザインパターン。これらは新しい技術ではありません。以前はこれらの技術を使うことで汎用性、拡張性などに富み、一時期はもてはやされた技術でした。

しかし、何も考えずさっと作ってしまうより、プログラミング前に設計するという工数、つまりコストが掛かってしまうデメリットがあります。

また、「はじめに」でも述べましたが、オブジェクト指向などが理解できず断念してしまったエンジニアも数多くいます。これらの理由から、オブジェクト指向は以前ほど使われなくなりました。

一方、現場では次々と発生する仕様変更や機能追加、障害対応など、システムを修正しなければならない状況で、オブジェクト指向などを取り入れずに設計を疎かにしていた場合、むしろ多大な修正工数が掛かることがあらためて分かり、「やはり必要な技術だ」ということが再認識され始めました。

そこで、これらの技術を必要と感じているエンジニアに向け、本連載でオブジェクト指向について分かりやすく順序立てて解説し、理解してもらおうと思ったのです。

オブジェクト指向、クラス設計、デザインパターン...本当に不要なのか？

ところで、一時期よりは影が薄くなってしまったオブジェクト指向、クラス設計、デザインパターン。これらは本当に不要なのでしょうか。

確かにプログラミング前に十分な設計を行わず、工数を掛けず一気に作ってしまうのも1つの方法ですが、仕様変更や機能追加、障害対応などが全く発生しない、という条件付きです。

このような、いわゆる「アジャイル開発」はスナップショット的（断片的）な観点で言うと早く仕上がり、メリットがあるように見えますが、実際の業務では仕様変更や機能追加などが頻繁に発生します。つまり、スナップショットで考えるのではなく、仕様変更へ対応できるように対策を講じなければなりません。

現在主流とも言えるアジャイル開発のように、さっと作ってしまうスタイルが流行るのは時代の流れで致し方ない点もあります。以前は開発に掛ける時間もお金も割と余裕があり、比較的開発期間を長く取ることができました。しかし現在では工数削減が叫ばれるようになり、以前ほど余裕をもって開発ができなくなっています（以前と違い現在では納期を守ることだけで精一杯になりました）。

残念な傾向ですが、その影響もあり現在ではオブジェクト指向で設計されたプログラミングコードを見ることは少なくなりました。

10年以上前の開発現場では、オブジェクト指向による洗練された設計が求められていたため、開発メンバー全員がオブジェクト指向やデザインパターンを知っていました。仮に知らない若手がいても先輩がレクチャーしてきたのですが、現在では知らない若手がいてもそれを教える先輩自身が知らないということが往々にしてあります。

このような影響もあり、オブジェクト指向やデザインパターンを知らない若手が多くなってきているのが現状です。

繰り返しになりますが、オブジェクト指向やクラス設計などを疎かにすると、仕様変更や機能追加などの影響を局所化できず、多大な修正工数が掛かることになります。

オブジェクト指向による設計では、カプセル化（隠蔽）や継承、委譲、インターフェースや抽象化などを行い、クラス間の結合度を下げることで修正の影響範囲を局所化し、最小限の工数で仕様変更、機能追加、障害対応などに対応できます。

しかし、オブジェクト指向やデザインパターンを適用した上でプログラミングをすれば何もかも上手くいき全て良い、という訳ではありません。もっと言えば「オブジェクト指向なんて考えは不要」という意見があることも知っています。

それでも不要とは考えず、本連載でオブジェクト指向、クラス設計、デザインパターンについて解説するのは、現場で抱えている開発工数不足などの問題点を解消するに補って余りあるメリットがあるためです。

オブジェクト指向は難しい？

「オブジェクト指向は難しい」という声をよく聞きます。確かにカプセル化や継承、委譲、デザインパターンなどを覚える必要があり、また、オブジェクト指向に不可欠なポリモーフィズム（多態性）といった分かり辛い言葉もより難しく感じさせてしまう要因になっている気がします。

しかし、オブジェクト指向は「現実世界のモノをそのままモデリングしたもの」であるため、本来は取っ付きやすい概念のはずです。

関数型プログラミング

最近では、オブジェクト指向プログラミングの後継と呼ばれる「関数型プログラミング」の必要性が謳われています。Java8からラムダ式が取り入れられたこともあり、本連載でも関数型プログラミングも取り扱います。

また、Javaの後継言語である関数型言語Scalaについても取り上げ、オブジェクト指向言語だけでなく関数型言語も学んでいきます。

ちなみに、筆者は「オブジェクト指向プログラミングと関数型プログラミングのどちらが良いか」ということではなく、「2つを上手く組み合わせたハイブリッドな考えでのプログラミング」が良いと考えています。

本連載の今後の展開

さて、今後の展開ですが、本連載では次回以降、下記のテーマを順次取り上げて解説する予定です。

・オブジェクト指向プログラミング
・クラス設計
・デザインパターン
・オブジェクト指向の設計原則
・ロバストネス図
・Javaラムダ式
・Scala言語

次回はサンプルプログラムを交えて「オブジェクト指向とは何か」から始め、「クラス設計」の基礎を学びます。「デザインパターン」ではStateパターン、Template Methodパターンなど、入門的なパターンを紹介します。

「オブジェクト指向の設計原則」では、とても重要な原則のオープン・クローズドの原則、単一責任の原則などを解説します。

また、「ロバストネス図」も取り上げます。ロバストネス図はUMLのコミュニケーション図やコラボレーション図と似ており、バウンダリー（境界）、コントロール（制御）、エンティティ（実体）という3つの要素を明確にし、クラス図の橋渡しにもなります。ここまでに、覚えておくべき基礎的な技術を学びます。

以降は、やや上級的な内容になります。Java8で取り入れられたラムダ式について解説します。ラムダ式でコーディングすることで、より簡潔にソースを書けるようになります。何よりJava8で用意された新機能がラムダ式前提のものが多数あるため、覚えておく必要があります。

さらには、Javaの後継言語Scalaを取り上げ、オブジェクト指向言語だけでなく関数型言語も学んでいきます。Scalaについては入門的な内容も解説しますが、Scalaで作られているツールを題材に、Scala言語でツールを拡張する応用編も解説する予定です。

おわりに

本連載は、よくある「〇〇を知っている人前提」ということを言いません。繰り返しになりますが、かつてオブジェクト指向、クラス設計、デザインパターンなどを書籍やネットで勉強したが挫折してしまった人でも分かるよう、どこよりも噛み砕いた分かり易い解説を目指します。最後までお付き合いいただければ幸いです。