継承（続き）

「継承」がOOにとって、どうやら並々ならぬ存在感を持っているらしい、で放置してしまいましたが、その続きです。

英語で書くと「インヘリタンス（inheritance）」gooの辞書で調べてみると、相続やら遺産やら伝統やら遺伝やら、そんな意味があるらしいです。

OOで言う「継承」とは、これらの意味とは若干異なり「対象を派生元と派生先に整理する」といった表現が近くなります。これをOOAの視点で説明しようとするとか、OODの視点で説明しようとするか、OOPの視（ｒｙ。。。によって、キーポイントが微妙に異なります。（だから、哺乳類インターフェイスに猫クラス、鳴くメソッドなんかが出てくるんだと思います）

OOAの視点で考えた場合

モデル化した際の複数個の要素に共通項が認められた場合で、その要素をグルーピングすること。

としておくと、近いと思ってます。
情報システムの基本的な機能「ユーザ認証」を例に取りますと、ユーザには少なくともシステム管理者や一般ユーザといった色分けが必要です。一般ユーザでも、管理職や一般職によって使用できる機能が制限されるかも知れません。

その場合、オブジェクトとして抽出されるものは、「ユーザ」「システム管理者」「一般ユーザ」「管理職」「一般職」の５つ。システム管理者と一般ユーザは、どちらもユーザです。同様に管理職も一般職も、一般ユーザです。
これを表現すると、

• ユーザ
  • システム管理者
  • 一般ユーザ
    • 管理職
    • 一般職

こんな箇条書きが可能なります。（UMLで書けばきれいになったんでしょうが。。。）この場合、「システム管理者」と「一般ユーザ」は「ユーザ」から派生した存在ですし、「管理職」「一般職」も同様です。

このように、対象の要素（存在だったり、役割だったり）にツリーな構造を持たせる事が「継承」です。

こうするメリットは何か？
システム管理者と一般ユーザの差異は、システムを使用する業務の中で非常に大きいものである筈です。システムを保守していく人（システム管理者）とシステムを使う人（一般ユーザ）です。この存在の差異は、人括りに「ユーザ」とまとめてしまうにはあまりに大きな差異です。が、どちらもシステムに対して操作を求められる事は同じです。（ここで、「ユーザ」という概念が出現する）

「一般ユーザ」から派生した「管理職」と「一般職」についても、同様に仕事の上で大きな差異を持っていますが、システムに対する操作は必要です。

こうして対象を整理する事で、「ユーザ認証」という機能が持つべきユーザ判別ルールが浮き彫りになっていきます。

上記のモデルは、「システムを触る人」→「それは誰？」→「どんな権限を持っている？」という順序で派生させてみました。こうすると、とても現実の業務での判定シーケンスに近づいたように見えますよね。

単純に「ログイン・ユーザ」と表現して終わりにするのではなく、その「ログイン・ユーザ」という存在の裏にどれだけの業務的な要件や存在の根拠があるのか、それを表現してみせるのが「継承」です。

（まだつづく）