At line 3 changed one line |
責務という言葉を言い換えると「しなければならないこと」「出来なければならないこと」となります。クラスを利用する側から見るとそのクラスが何を出来るか(してくれるか)は確かに重要です。\\ |
責務という言葉を言い換えると |
*しなければならないこと |
*出来なければならないこと |
となります。クラスを利用する側から見るとそのクラスが何を出来るか(してくれるか)は確かに重要です。\\ |
At line 21 changed one line |
Javaなどでは「Interface」として定義するのが責務です。Interfaceはメソッドを規定するだけで中身は実装者任せです。まさに、「責務は決めるがモノは決めない」という機能です。ちなみに私はInterfaceのことを責務ではなく「役割」と呼ぶようにしています。このページでは責務と役割を同義として書いています。 |
Javaなどでは「Interface」として定義するのが責務です。Interfaceはメソッドを規定するだけで中身は実装者任せです。まさに、「責務は決めるがモノは決めない」という機能です。ちなみに私は |
*Interfaceのことを__役割__と呼ぶ |
ようにしています。このページでは責務と役割を同義として書いています。 |
At line 38 added one line |
\\ |
At line 42 changed 2 lines |
人事システムを設計する際に「ジムの会員」という役割を考慮する必要は現実にはないと思います。人事システムから見れば「人間=従業員」という構図は成り立つので、そのシステムで従業員をクラスとして定義することは正しいと思います。\\ |
しかしそれはシステム設計上便宜的に行っている省略であることを忘れてはいけません。役割をクラスと勘違いした結果の上記のような誤った設計/実装を大変多く見かけます。\\ |
人事システムを設計する際に「ジムの会員」という役割を考慮する必要は現実にはないと思います。人事システムから見れば「人間=従業員」という構図は成り立つので、従業員をクラスとして定義することは人事システム設計上正しいと思います。\\ |
しかしそれはシステム設計上便宜的に行っている省略であることを忘れてはいけません。役割(責務)をクラスと勘違いした結果の上記のような誤った設計/実装を大変多く見かけます。\\ |
At line 47 changed one line |
オブジェクト(またはクラス)が持つ責務として世間で見かける解説では、 |
オブジェクト(またはクラス)が持つ責務として世間で見かける解説には、 |
At line 51 changed one line |
業務に必要な処理というのをジュース売りを例に取ると「注文を聞く」などがそれです。これはその通りそのクラスが負うべき責務です。\\ |
ジュース売りの例の中で業務に必要な処理というのは「注文を聞く」などです。これはその通りそのクラスが負うべき責務です。しかしそのクラス(もの)が何であるか、つまりデータ構造を規定できないことは上記で書いたとおりです。\\ |
At line 69 added one line |
|
At line 73 changed one line |
一方でこれらの伝票をRDBに保存したいような場合は、「RDBを読み書きする」というシステム的な役割も負います。 |
一方で、これらの伝票をRDBに保存したいような場合は「RDBを読み書きする」というシステム的な役割も負います。 |
At line 80 changed 2 lines |
この例においてRDBを読み書きする役割を別のクラスに分けてしまうとそのクラスはデータを持たない処理だけのクラスになってしまい、「データ構造としての伝票クラス」と「RDBを読み書きする処理のクラス」の2つに結局分割されることになり、データ構造と処理を一体化させるためのクラスという原理から外れてしまいます。\\ |
ただし、同じ伝票クラスの情報を「テキストファイルに出力したい」という新たな要件が出てくると新たなメソッドを伝票クラスに実装する必要がまた出て来ます。その次はネットワークに出力したい等も考えられ、出力媒体が出てくるたびに処理を追加する必要が出て来ます。この問題への対応は別ページで書きます。\\ |
この例においてRDBを読み書きする役割を別のクラスに分けてしまうとそのクラスはデータを持たない処理だけのクラスになってしまい、 |
#データ構造としての伝票クラス |
#RDBを読み書きする処理のクラス |
の2つに結局分割されることになり、データ構造と処理を一体化させるためのクラスという原理から外れてしまいます。\\ |
ただし、同じ伝票クラスの情報を「テキストファイルにも出力したい」という新たな要件が出てくると新たなメソッドを伝票クラスに実装する必要がまた出て来ます。その次はネットワークに出力したい等も考えられ、出力媒体が出てくるたびに処理を追加する必要が出て来ます。この問題への対応は別ページで書きます。\\ |
At line 85 changed one line |
クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、「システムでxxxがしたい」「システムを使ってmmmが出来るようになりたい」という実務処理の記述です。裏返すと、「システムはxxxが出来なければならない」「システムはmmmというサービスを提供しなければならない」となります。つまりシステムの役割・責務を列挙したものです。\\ |
クラスを設計する際、その基となるのは顧客からの要求です。要件と呼ばれます。この要件は、 |
*システムでxxxがしたい |
*システムを使ってmmmが出来るようになりたい |
という実務処理の記述です。裏返すと、 |
*システムはxxxが出来なければならない |
*システムはmmmというサービスを提供しなければならない |
となります。つまりシステムの役割・責務を列挙したものです。\\ |
At line 87 changed one line |
しかし、オブジェクト指向に不慣れな設計者・実装者はその要件(処理)だけを頼りに開発してしまいます。データ構造を考えずに処理だけを追いかけてしまうのです。これが誤りの根本です。 |
しかし、オブジェクト指向に不慣れな設計者・実装者はその要件(処理)だけを頼りに開発してしまいます。 |
*データ構造を考えずに処理だけを追いかけてしまう |
のです。これが誤りの根本です。 |
At line 95 changed one line |
責務という言葉の解釈によってこのページで書いたことは変わってくるとは思っています。つまり責務という意味の中に「データ構造を持つこと」を含むかどうかです。\\ |
責務という言葉の解釈によってこのページで書いたことは変わってくるとは思っています。つまり責務という意味の中に |
*データ構造を持つことを含むかどうか |
です。\\ |
At line 98 changed one line |
一方で、「責務を全うするためにはデータ構造が必要となる」とは言えます。しかしだからと言って、責務を考えた結果データ構造が導き出せるとは私の経験上思えません。\\ |
一方で、 |
*責務を全うするためにはデータ構造が必要となる |
とは言えます。しかしだからと言って、責務を考えた結果だけでデータ構造を導き出せるとは私の経験上思えません。\\ |
At line 101 changed 4 lines |
*手続き型 |
*構造化 |
*データ中心主義 |
*オブジェクト指向 |
#手続き型 |
#構造化 |
#データ中心主義 |
#オブジェクト指向 |