Парсер Хабра: [Перевод] Tell Don't Ask

пятница, 6 сентября 2013 г.

[Перевод] Tell Don't Ask

Tell Don't Ask является принципом, который помогает вспомнить, что объектно-ориентированное программирование предназначено для связки данных и функций, которые их обрабатывают. Принцип напоминает нам, что вместо того, чтобы спрашивать данные у объекта, мы должны сказать объекту что с ними делать. Для этого все поведение объекта надо заключить в его методы.

Разберемся на примере. Давайте представим, что нам нужно контролировать сигнализацию, которая сработает, если число поднимется выше определенной планки. Если мы напишем это в стиле «ask», мы получим структуру данных…


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");

«Tell Don't Ask» напоминает нам, что поведение следует описать внутри объекта(используя те же поля):


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);

Многие люди находят принцип «Tell Don't Ask» полезным. Одним из фундаментальных принципов объекто-ориентированного дизайна является совмещение данных и поведения, поэтому простые элементы системы (объекты) совмещают это в себе. Часто это хорошо, потому что данные и их обработка тесно связанны: изменения в одном вызывают изменения в других. Вещи, которые тесно связанны должны быть одним компонентом. Помнить об этом принципе поможет программистам увидеть, как можно совмещать данные и поведение.

Но лично я не использую этот принцип. Я просто стараюсь размещать в одном месте данные и поведение, что часто ведет к тем же результатам. Одна из проблем — этот принцип стимулирует людей убирать методы запрашивающие информацию. Но бывает, когда объекты эффективно сотрудничают предоставляя информацию. Хорошим примером будут объекты, упрощающие информацию для других объектов. Я видел код, который на столько закручен, что подходящие запрашивающие методы решили бы эту проблему. Для меня «проси, а не спрашивай» шаг к объединению поведения и данных, но это не первоочередная задача.

Прим. переводчика: я сомневаюсь в необходимости перевода названия принципа, но как один из вариантов предлагаю — «проси, а не спрашивай»

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: