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のことを責務ではなく「役割」と呼ぶようにしています。

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

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

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

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

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

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

まとめ#

• 役割(責務)をクラスにしてはいけない

何をクラスにするのか