This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

責務でクラスは決まらない#

「責務」によってクラスが定義されるといくつかの解説書には書いてありますが、これは誤りだと私は考えています。誤りが言い過ぎだとしても、初学者に大きな誤解を与えています。
責務という言葉を言い換えると「しなければならないこと」「出来なければならないこと」となります。クラスを利用する側から見るとそのクラスが何を出来るか(してくれるか)は確かに重要です。
ですがそれはクラスを使う側から見た場合であって、設計する人はそれだけではクラスを定義出来ません。一つ例を出します。

「ジュース売り」という責務#

「ジュース売り」という責務を考えてみます。
ジュース売りがしなければならないことは次のような事です。

1. 注文を聞く
2. 金額を伝える
3. お金をもらう
4. 品物とお釣りを渡す

では、この責務を請け負えるモノは何が考えられるでしょうか?

ジュース売りを請け負えるモノ#

• 人間
• 自動販売機

ジュース売りを請け負えるモノとして少なくともこの2つが考えられます。将来的には「ロボット」も入ってくるかもしれません。
ジュースを買いたいという利用者側から見れば、それが人間だろうが自販機だろうが要件は満たされます。つまり責務が決まったからと言ってそのモノまでは決められないのです。
これは当然で、「何が出来るのか」というのは処理の規定であって、データ構造、つまりそのモノの状態は関係無いからです。
Javaなどでは「Interface」として定義するのが責務です。Interfaceはメソッドを規定するだけで中身は実装者任せです。まさに、「責務は決めるがモノは決めない」という機能です。ちなみに私はInterfaceのことを責務ではなく「役割」と呼ぶようにしています。

責務で考えると誤ったクラスが出てくる例#

従業員を考えてみます。業務システムを設計する際に「従業員クラス」というのは良く出て来ます。


また、スポーツジムの管理システムを設計すると「ジムの会員クラス」もあります。


これらをある1人の人の視点から見るとクラス図は次のようになります。

ですがよく考えてみるとこれらの中でモノと呼べるのは人間だけです。従業員やジムの会員は、その人がその時その時に負っている役割に過ぎません。責務と言い換えてもいいでしょう。会社の中で負っているのが従業員という役割、ジムに行けば会員という役割に変わりますが、実体としては同じ人です。
これを正しいクラス図にすると次になります。


人事システムを設計する際に「ジムの会員」という役割を考慮する必要は現実にはないと思います。人事システムから見れば「人間=従業員」という構図は成り立つので、そのシステムで従業員をクラスとして定義することは正しいと思います。
しかしそれはシステム設計上の便宜性から来るものであることを忘れてはいけません。役割をクラスと勘違いした結果の上記のような誤った設計/実装を大変多く見かけます。

責務をもう少し掘り下げてみる#

責務というのは英語の'responsibility'の訳です。一般的には「責任」と訳します。
オブジェクト(またはクラス)が持つ責務として世間にある解説では、

1. 業務に必要な処理のこと
2. オブジェクトが持っている情報を通知すること

と書いてあります。
業務に必要な処理というのはジュース売りを例に取ると「注文を聞く」などがそれです。これはその通りそのクラスが負うべき責務です。
「オブジェクトが持っている情報を通知すること」は内部にデータ構造がないと不可能なので、データ構造に依存するかのような説明に見えます。しかし、情報を通知するということはどんなオブジェクトにも必要な処理であって特定の業務とは無関係です。これをオブジェクトの責務と呼ぶのは勘違いだと私は考えます。オブジェクト指向においてオブジェクトに与えられている機能と言うべきでしょう。
責務というのはそのクラスがシステムの中で果たすべき業務的な役割のことであって、仕組みとして備わっている機能のことを呼ぶべきではないと言うのが私の考えです。責務はやはり処理を規定するだけでデータ構造には依存しないのです。

みんななぜ間違うのか?#

世間ではクラスと思われているものが実は誤りである。なぜそうなってしまうのでしょうか?
クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、「システムでxxxがしたい」「システムを使ってmmmが出来るようになりたい」という実務処理の記述です。つまりシステムの役割を列挙したものです。
役割というのは上で書いたように処理に過ぎません。クラスとして必要なデータ構造はそれだけでは出て来ません。
ですが、オブジェクト指向に不慣れな設計者・実装者はその要件(処理)だけを頼りに開発してしまいます。データ構造を考えずに処理だけを追いかけてしまうのです。これが誤りの根本です。

まとめ#

• 役割(責務)をクラスにしてはいけない
• 要件だけに着目してもクラスは見つけられない

次 何をクラスにするのか