翻訳: 尋ねるな、命じろ

この記事は以下のMartin Fowler氏のブログ記事の翻訳です。

TellDontAsk
http://martinfowler.com/bliki/TellDontAsk.html

翻訳日: 2014/1/19

尋ねるな、命じろ

「尋ねるな、命じろ」は、オブジェクト志向はデータをそれを操作する関数と一緒に構成する事である、というのを思い出させてくれる原則だ。 あるオブジェクトに対して、問合せによってデータを取得し、それに対して変更を加えるのではなく、オブジェクトに何をしてほしいか命令すべきであると 気づかせてくれる。そのデータと一緒になるように、振る舞いもオブジェクトに移すよう推奨している。

例を使って説明しよう。ある値を監視して、限界値を上回ったらアラームにシグナルを送信する必要があると想定しよう。これを「尋ねる」スタイルで書くと、まずこれらを表すデータ構造を作るだろう。

class AskMonitor...
  private int value;
  private int limit;
  private boolean isTooHigh;
  private String name;
  private Alarm alarm;
    
  public AskMonitor (String name, int limit, Alarm alarm) {
    this.name = name;
    this.limit = limit;
    this.alarm = alarm;
  }

そしてこのデータを取得するためのアクセサーと組み合わせて、

class AskMonitor...
  public int getValue() {return value;}
  public void setValue(int arg) {value = arg;}
  public int getLimit() {return limit;}
  public String getName()  {return name;}
  public Alarm getAlarm() {return alarm;}

このデータ構造を下記のように使うだろう

AskMonitor am = new AskMonitor("Time Vortex Hocus", 2, alarm);
am.setValue(3);
if (am.getValue() > am.getLimit()) 
  am.getAlarm().warn(am.getName() + " too high");

「尋ねるな、命じろ」はこのようにするのではなく、(いくつかのフィールドを使って)この振る舞いを、モニターオブジェクト自体に持たせるよう思い起こさせる。

class TellMonitor...
  public void setValue(int arg) {
    value = arg;
    if (value > limit) alarm.warn(name + " too high");
  }
TellMonitor tm = new TellMonitor("Time Vortex Hocus", 2, alarm);
tm.setValue(3);

多くの人が「尋ねるな、命じろ」を役に立つ原則だと考えている。オブジェクト指向設計の根本原則のひとつは、システムの基本的な要素がそれらをうまく統合するように、データと振る舞いを組み合わせることだ。これはしばしば良いことだ。データと振る舞いの結びつきは強い。一方を変更すれば他方も変更せざるを得なくなる、また一方を理解すれば他方も理解しやすくなる。結びつきがつよいものは同じコンポーネントにいるべきなのだ。「尋ねるな、命じろ」について考える事によってプログラマーは、どうすれば同じ場所に置くことができるか分かるのである。

ただ個人的には私は「尋ねるな、命じろ」は使わない。もちろんデータと振るまいを同じ箇所に置こうとはするので、ほとんどよく似た結果になる。 一つ「尋ねるな、命じろ」で問題だと思うのは、この原則のせいで「GetterEradicators」になって、すべての問い合わせメソッドを取り除こうとする人を見たことがあることだ。しかし、情報を提供することで効率的にオブジェクトが協調して動作することもある。よい例は、入力情報を変換することでクライアントを簡素できる「usingEmbeddedDocumment」のようなオブジェクトがある。適切な責任をもたせた問い合わせメソッドを使えば簡単になるのに、命令メソッドのみが複雑に絡み合っているコードを見たこともある[1]。私にとっては、「命じろ、尋ねるな」は振る舞いとデータを一緒の場所に置くための一つの手段ではあるが、注目すべき主張だとは思わない。

さらに詳しく

この原則に一番関連しているのはAndy Huntと"Prag" Dave Thomas(The Programatic Programmers)だ。彼らはIEEEソフトウェアのコラム自らのWebサイトのポストでこれについて書いている。

脚注

1.それにまた、データと振る舞いを同じ場所に置くべきというより根本的な原則でさえも、時に他の観点、たとえばレイヤー化などのために破棄される。よいデザインとはともかくトレードオフであり、データと振る舞いを同じ場所にとくべきというのは留意すべき一つの要因にすぎない。

Comments

blog comments powered by Disqus