Декомпозиция и перераспределение метода statement

Страница 15

Это то, что получилось:


  private double amountFor( Rental aRental) {
    double result = 0;
    switch( aRental.getMovie().getPriceCode()) {
      case Movie.REGULAR:
        result += 2;
        if( aRental.getDaysRented()>2)
          result += ( aRental.getDaysRented()-2)*1.5;
        break;

      case Movie.NEW_RELEASE:
        result += aRental.getDaysRented()*3;
        break;

      case Movie.CHILDRENS:
        result += 1.5;
        if( aRental.getDaysRented()>3)
          result += ( aRental.getDaysRented()-3)*1.5;
        break;
    }
    return result;
  }

После переименования я запустил компиляцию и тесты, чтобы убедиться, что ничего не сломалось.

Стоит ли переименование затраченных стараний? Абсолютно. Хороший код должен понятно излагать, что он делает, и названия переменных -- ключ к понятному коду. Никогда не бойтесь менять имена для улучшения прозрачности. С хорошей утилитой для поиска и замены обычно это несложно. Строгая типизация и тестирование выявят всё, что Вы упустили.

Любой дурак напишет программу, понятную компьютеру. Хорошие разработчики пишут код, который может понять человек.

Код, который сам говорит о своём назначении, очень важен. Я часто делаю рефакторинг, когда просто читаю чужой код. Так я получаю понимание программы и встраиваю это понимание в код на будущее; таким образом я не теряю то, чему научился.

Оглавление | << страница 14 | страница 16 >>