(Photo by：Sacha Chua)
オブジェクト指向の背景
オブジェクト指向が登場する前、データ構造を中心とした構造化技法という手法が中心でした。アプリケーションが大規模になるに従い、構造化技法だけでは限界がでてくるようになりました。
そんな時、「部品の再利用」というニーズにしたがって誕生したのが、オブジェクト指向という設計方法です。
オブジェクト指向はデータ設計の技法であり、部品化して再利用を目的とした設計です。部品化することによってプロジェクトのコードを他のプロジェクトでも使用できるようになるのですが、そのためには高い設計センスが必要となります。
オブジェクト指向は登場とともに広がり、オブジェクト指向型言語なども登場して一気に広まりを見せました。身につけておいて損はないものです。
特に大規模で複雑なシステムを構築するにはオブジェクト指向の考え方が欠かせません。
カプセル化
オブジェクト指向の重要かつ中心的な概念のひとつに、カプセル化があります。
これは設計をオブジェクトに分割していく過程で、各オブジェクトの内部構造を外部から見せないという決まりです。これをカプセル化といいます。
クラスとインスタンス
クラスとインスタンスもオブジェクト指向の重要な概念です。
クラスは構造化したモデルを元に、振る舞いを記述したものです。インスタンスはそれの実態です。いわば電話というモデルがクラスで、iPhoneがインスタンスのようなもの。設計図と実際に建てられた家、というような表現もできるかもしれません。
プログラミングでは「new」を使ってインスタンスを実体化します。
継承
オブジェクトの機能が似通っている場合、作り直すのではなくて継承という概念で上位のクラスを引き継ぎます。これによってプロジェクトが別のものであっても以前のオブジェクトが使用可能になったり、上位のプロパティやメソッドを使うことが可能になります。上手に使わないと設計図がオブジェクト指向とはかけ離れたものになってしまいます。
オブジェクト指向の協調をハンバーガーチェーンで理解する
例えば、「ハンバーガーチェーンにおける商品の注文」を考えて見ましょう。
顧客が来てから、レジでオーダーを受ける人、ハンバーガーを作る人、ポテトを揚げる人、レジの後ろでドリンクを作って仕上がった品物をトレーに配置する人、全体を管理するマネージャー、いろいろな役割を持った人たちによって運営されています。
(Photo by：Cortney Martin)
レジの担当者はオーダーと精算と行列の進行(注文を受け、レジ入力し、生産に依頼)というメソッドが必要で、ハンバーガーを作る人(生産)はオーダーの確認とバーガーの成型業務がメソッドとしてあり、ポテトの担当者はポテトの補充や油の管理、塩を振ると言うメソッドが必要です。
レジの後ろにいる人はレシートを見ながらドリンクの手配をして出来上がったバーガーをトレイにおくメソッドが必要です。そして全体を管理するマネージャーはレジにいる行列以外の顧客の話を聞いたり、全体の流れを指示したりします。
ここでクラスはハンバーガースタッフであり、プロパティとして従業員番や敬語などの接客スキルなどの各自共通の機能を持っています。スタッフと言うクラスを継承したサブクラスとして、各スタッフの個別クラスがあります。ハンバーガー成型などの機能は上位の従業員クラスではなくサブクラスのハンバーガースタッフクラスに定義されます。スタッフのクラスのインスタンスはレジが2名、ポテトが1名、バーガー担当が1名、マネージャーが1名、レジの後ろが2名などの複数の生成が可能です。
そしてこの各クラスの複合的な動きと連携により、ハンバーガーをオーダーすると言う機能の振る舞いが定義されるのです。
ハンバーガースタッフ共通の定義が社員番号や敬語などの基本スキル、各サブクラスの実装がレジやポテト担当などの個別のメソッド、従業員の実態がインスタンスとなります。
MVCモデル
オブジェクト指向プログラミングで設計を行うときに、ベースとなる設計モデルがあります。それがMVCモデルのアーキテクチャです。Model View Controllerに別れて、モデルはよりデータベースに近い構造体のような存在、Viewはユーザーに近い表示機能、コントローラーはその振る舞いを定義する機能を持っています。多くのシステムがこのMVCモデルで構築されており、可読性も非常に高く使いやすい設計の基本です。
オブジェクト指向を実現するためのプログラミング言語
はじめからオブジェクト指向プログラミングを実装するために書かれた言語があります。代表的なものはJava,C++,Rubyなどです。C++はもともとC言語から拡張されたもので、データベースに弱かったC言語にクラスの機能を実装し、よりデータベース管理が楽になりまたモデル設計ができるようになったものです。
JavaはC++を拡張した言語であることはあまり知られていませんが、C++で厄介だったメモリ管理を自動で行い、メモリの開放をVM(バーチャルマシン)に任せたプログラミング言語で、クラスなどの基本概念をC++から受け継いでいます。Rubyは日本発のプログラミング言語で、非常にわかりやすく、日本語に近い言語です。オブジェクト指向型言語であり、オブジェクトのメソッドを実行することで機能を呼び出します。正規表現などもクラスで実装されている非常にユニークかつオブジェクト指向に特化したプログラミング言語です。
(Photo by：Manuel Gonzalez Noriega)
デザインパターン
オブジェクト指向の設計にはいくつかの「型」があります。
このような機能にはこのようなオブジェクトの設計がふさわしいと言う基本パターンです。
それがデザインパターンです。これにより設計にかかる時間が短縮されますので、オブジェクト指向設計をはじめたら、まず最初にデザインパターンの模倣から始めましょう。デザインパターンについてはたくさんの本が販売されており、書店で手に入れることができます。オリジナルの設計を行うのはデザインパターンを理解してからの方がスムーズです。
またデザインパターンは多くのエンジニアが学習していますので、デザインパターンを理解するときにエンジニア間のコミュニケーションが取りやすくなると言うメリットもあります。開発者同士の意思疎通が容易になることでプロジェクトの進みが大変良くなるのは感覚的に理解できることでしょう。
再利用
そもそもオブジェクト指向の概念は、書いたコードを別のプロジェクトでも再利用したいと言う要求から生まれたものだと言うのはあまり知られていません。実は再利用を目的としており、そのため上位クラスは抽象度の高い設計になることがしばしばです。
再利用ならばモジュール化でいいじゃないかと思われるかもしれませんが、モジュールのように機能だけを分離したものではなく、プロパティとメソッドごとひとつのクラスにまとめてしまったのがオブジェクト指向の再利用です。上手に設計されたクラスでは別プロジェクトでもソースコードの再利用が可能となり、コード記述量の削減が可能となります。代表的なものはJavaそのものに用意されたクラスで、しっかりと設計されています。リファレンスを眺めるだけでも、再利用されやすい設計とはどのようなものか理解できることだと思います。
スピードが遅い？
オブジェクト指向言語が実際にどうコンピュータ上で動作するのかイメージしてみてください。
newされるとメモリの上にクラスが展開されます。そのクラス上には、必ずしも使われないプロパティもあるでしょう。それらもまとめてメモリ上の場所をとるのです。そのため、オブジェクト指向の登場当時は、メモリを食う、動作が遅くなるなどの批判があったようです。ですが現在ではコンピュータのスペックも大幅に増加しており、メモリについての心配はほとんどなくなりました。逆に言うと今後はメモリを丁寧に扱うCやC++などの言語の出番は少なくなり、多少メモリを食っても可読性が高くてコードが美しくなるJavaやRubyなどが主軸で活躍すると言うことでしょう。
オブジェクト指向は難しい？
オブジェクト指向をことばで説明するのは非常に困難を極めます。書くほうですら難しいのですから読む側もさらに難しいでしょう。このようにオブジェクト指向は難解だというイメージが付きまとっています。理解するには上述のハンバーガーの仕事の流れをオブジェクト指向で理解するように、ストーリーで理解したりすることです。何よりも理解が進むのは、上級者が書いた美しいオブジェクト指向の設計図を見て、具体的に何がどのように定義されているのか現実のコードを見ることです。
概念自体は非常に抽象度が高いものですので、抽象的な理解だけでは現実のコードを書くことは難しいでしょう。やはりリアルなコードや設計図をみて、感覚的に理解していくようにしてください。
(Photo by：By: Juhan Sonin)
美しい設計で書かれたオブジェクト指向言語はコードも美しい
オブジェクト指向は難しいですが、上達すると非常に美しいコードが書けるようになります。
例えばCOBOLは非理系向けに開発されたプログラミング言語で、大胆なグローバル変数がありGOTOだらけで下手するとめちゃくちゃなスパゲッティコードになってしまいます。書く側は思いつきでかけるので初心者でもかけるのですが、保守性が非常に悪いのです。
一方でRubyなどはもともとオブジェクト指向型がの言語であるために、非常に可読性が高く美しいコードになるのです。コードがきれいということは可読性も高まり、保守性があがるのです。難易度は高いですが結果としてプロジェクト予算の削減になります。
オブジェクト指向のデメリット
最後にデメリットも掲載しておきます。オブジェクト指向開発のデメリットは、まず設計の工程に時間がかかること。そして実際に再利用するとなると非常に難易度が高いこと。最後に、深く理解したエンジニアを確保するのが困難であることが挙げられます。やはり設計を上手に行うには難易度が高く、優れた要員を確保することが急務でしょう。
本ブログは、Git / Subversion のクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。
開発の効率化をしたい！もっと便利なツールを使いたい！そんなお悩みをtracpathで解決！
「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。
