今回は今までの記事とは少し違ったことを書きます。それは、オブジェクト指向です。オブジェクト指向言語を初めて覚えるときに、障壁となるものがいくつかあります。インターフェースクラスとアブストラクトクラスです。WikiPedia ではそれぞれ下記のように説明しています。
- インターフェースクラス
オブジェクト指向プログラミングにおいて、複数の種類のオブジェクトに関して共通する機能を実装するためのメッセージの規格を定義したもの。あるインタフェースに従ったメッセージを送受信できるようにすることを、そのインタフェースを実装するという。 - アブストラクトクラス
ソフトウェア工学における抽象型（ちゅうしょうがた、英: abstract type ）は、プログラマが宣言する nominative type system における型である。何らかの宣言された派生型のメンバーも共有するメンバーを含む抽象メソッドやプロパティを含むこともあるし、含まないこともある。多くのオブジェクト指向プログラミング言語では、抽象型を抽象基底クラス ( abstract base class )、インタフェース ( interface )、Trait、Mixin、flavors、roles などと呼ぶ。これらの名称はそれぞれ異なる言語での抽象型の実装を指している。本項目ではこれを総称して抽象クラス ( abstract class ) と呼ぶ。抽象クラスの最大の特徴は、オブジェクト指向プログラミングをよりオブジェクト指向的に保つことと、その性質上それが未完成である点である。
オブジェクト指向言語を初めて勉強する人にとって、これは日本語だけど日本語でない、かなり異質なものに映ると思います。( 私もそうでした。) これらの概念は覚えてしまえばはっきり言って大したものではないのですが、理解できなければオブジェクト指向言語の恩恵をまったく受けることができません。ましてや、これらの概念を覚えずに GoF のデザインパターンのお話を上司から説明された日には頭の中が.....という感じになると思います。
例えば、頻用するデザインパターンの一つである、テンプレートメソッド、ファクトリ、コマンドの説明は Wikipedia では下記のようになっています。
- テンプレートメソッド
Template Method パターン（テンプレート・メソッド・パターン）とは、GoF( Gang of Four; 4人のギャングたち)によって定義されたデザインパターンの1つである。「振る舞いに関するパターン」に属する。Template Method パターンの目的は、ある処理のおおまかなアルゴリズムをあらかじめ決めておいて、そのアルゴリズムの具体的な設計をサブクラスに任せることである。そのため、システムのフレームワークを構築するための手段としてよく活用される。 - ファクトリ
Factory Method パターン（ファクトリメソッド・パターン）とは、GoF ( Gang of Four ; 四人組)によって定義されたデザインパターンの1つである。 Factory Method パターンは、他のクラスのコンストラクタをサブクラスで上書き可能な自分のメソッドに置き換えることで、 アプリケーションに特化したオブジェクトの生成をサブクラスに追い出し、クラスの再利用性を高めることを目的とする。 - コマンド
Command パターン（英: command pattern ）はオブジェクト指向プログラミングにおけるデザインパターンの一つで、 動作を表現するオブジェクトを示す。command オブジェクトは、動作とそれに伴うパラメータをカプセル化したものである。
オブジェクト指向がわからない人にとっては、もう頭真っ白です。講義などでこんな説明をされると 10分 もかからず熟睡することができるでしょう。デザインパターンを習得するには、その基礎となるインターフェースおよびアブストラクトクラスの習得が必須です。しかし、ほとんどの本においては、上述のような解説に終始しているものが多いように思います。
私は最近、インターフェースとアブストラクトを教えるときには、会社の組織を例にとって教えています。クラス図を記述すると下図のようになります。
- とてもえらい方
方針を決定するとてもえらい方です。自分自身は特になにもしません。 - とても忙しい中間管理職
とてもえらい方が決めた方針を部下に伝える人です。様々な社内外の人間と連携し、部下にとって動きやすい方法 ( メソッド ) を提供します。しかし、自分自身が働いて ( インスタンス化 ) はいけません。 - 部下
とても忙しい中間管理職のメソッドを駆使し、方針を実行に移します。しかし、すべてをとても忙しい中間管理職に頼れるわけではないので、部下同士で便利なやり方集 ( ユーティリティ ) を作成し、共同利用することで、仕事の生産性を向上 ( ステップ数の削減 )させたりします。
どうでしょうか？ 分かりやすいかどうかわかりませんが、参考にしてみてください。(ご意見いただけるとうれしいです。) 組織と同じなので、とてもえらい方がご乱心して、方針( = interface )がコロコロ変わってしまうと、中間管理職、部下が再度仕事を組み直す(再実装)ことを余儀なくされてしまいます。組織・クラス設計は方針 ( = interface ) はをきちんと考えた上で決定しましょう。
