Tell, Don’t Ask～尋ねるな、命じよ

2023年7月7日2024年11月19日

オブジェクト指向において、メソッド呼び出し関係をどうするか、の考え方です。

尋ねるな、命じよ

Tell, Don’t Ask

オブジェクトに、データを要求するのでなく、何をすべきかを指示すること

オブジェクトには、やることをズバッと指示しましょう、ということです。

どんなとき使うの？

get, get, get…と並んでるとき

新人くん

ふんふーん♪

String name = employee.getName();
int age = employee.getAge();
String address = employee.getAddress();
String phoneNo = employee.getPhoneNo();
...

リーダーさん

get 呼んでばっかりだけど、呼び出し元で色々やりすぎなんじゃない？

「getしてgetしてgetして、なんか処理…」わりとよく見かけるコードかも。

でも、オブジェクト指向的にはイケてない。

呼び出し元で色々やりすぎ問題

手続き型プログラミングに慣れた人がやりがち

「getしてgetしてgetして、なんか処理…」とやるときは、だいたいこんな考え方をしています。

呼び出す側のクラス　　：　処理を担当
呼び出される側のクラス：　データ管理を担当

手続き型プログラミングでは「処理とデータを分割する」という考えがあります。しかしこれをすると、呼び出し元クラスにすべての処理が集中しがちです。

ドメインモデル貧血症 と呼ばれるアンチパターンです。

オブジェクト指向プログラミングでは、「責任で分割する」の考えが大事になります。単一責任原則 ですね。

その作業について責任を持つ人に、作業を依頼する。そういう考え方が重要です。

呼び出す側のクラス　　：　作業を依頼する人
呼び出される側のクラス：　責任もって作業する人

リーダーさん

単一責任原則 にのっとったクラス分割が大事！

getterがあるのが悪いわけではない

この話をすると、

ベテランさん

getterがあるのが悪いんだ！getterを撲滅せよ！

となりかねませんが、それは話が違います。

getterがあること自体は、問題ないのです。あったほうが便利なこと多いですし。

同じオブジェクトに対して何回も問い合わせする。これが良くない。

責任で分割するなら、やってほしいことを１回で伝えて任せましょう。そのほうが、責任分界点が明確になります。

リーダーさん

オブジェクトには、１回でやることを指示しよう！

先輩と後輩の関係にも似ている…

この関係、なんだか、先輩と後輩の関係にも似ています。

先輩が後輩に指示します。こんな先輩いませんか？

先輩その１

「あれはどうなってる？」
「これはどうなった？」
「ええい、もうおれがやる！」

一方、こんな先輩もいます。

先輩その２

「これ、お願いね！」

どちらのほうが、円滑に仕事がまわるか、分かりますよね？

適切に権限を委譲することは、プログラムにおいても、組織においても、大切ですね。

まとめ

「getしてgetしてgetしてなんか処理…」という処理、安直に思いつきやすいです。

深い考えなしにクラス設計すると、このパターンに陥りがち。

責任分割を意識したクラス設計をしましょう。

Tell, Don’t Ask～尋ねるな、命じよ