Главное в этой книге то, что она поддерживает процесс создания программ в хорошей форме. [Книга] способствует вашему постоянному росту и явно написана людьми, знающими толк в программировании.

Кент Бек, автор книги Extreme Programming Explained: Embrace Change

 

   Я обнаружил, что эта книга является смесью убедительных советов и замечательных аналогий!

Мартин Фаулер, автор книг Refactoring и UML Distilled

 

   Я бы купил книгу, прочел ее дважды, а затем сказал бы всем моим коллегам, чтобы они скорее бежали в магазин и купили себе по экземпляру. Эту книгу я никогда не дал бы никому почитать, так как сходил бы с ума от беспокойства за ее сохранность.

Кевин Руланд, сотрудник отдела менеджмента фирмы MSG-Logistics

 

   Мудрость и практический опыт авторов очевидны. Разделы, представленные в книге, уместны и полезны… Сильнейшее впечатление на меня произвели выдающиеся аналогии – стрельба трассирующими, разбитые окна и фантастическое по своей аналогии с управлением вертолетом объяснение необходимости ортогонального подхода, что особенно важно в критической ситуации. Я практически не сомневаюсь, что эта книга станет превосходным источником полезной информации как для начинающих программистов, так и для умудренных опытом мэтров.

Джон Лакос, автор книги Large-Scale С++ Software Design

 

   Когда такие книги появляются на прилавках магазинов, я покупаю по десять экземпляров для раздачи моим клиентам.

Эрик Вот, инженер-программист

 

   Большинство современных книг по разработке программ не в состоянии охватить основ становления программиста-мастера. Они тратят время на спецификацию синтаксиса или технологии, тогда как на самом деле движущей силой любой команды является наличие талантливых программистов, которые реально владеют своим ремеслом. Отличная книга.

Пит Макбрии, независимый консультант

 

   Прочитав книгу, я реализовал много из тех практических предложений и подсказок, которые дают нам авторы. Честно говоря, они сэкономили моей фирме время и деньги, помогая выполнить работу быстрее! "Программист-прагматик" должен стать настольной книгой для всех, кто зарабатывает на жизнь программированием.

Джаред Ричардсон, старший программист фирмы iRenaissance, Inc.

 

   Я хотел бы, чтобы эта книга попала ко всем новым сотрудникам моей фирмы.

Крис Клилэнд, Старший инженер-программист фирмы Object Computing, Inc.

   Книга, которую вы сейчас держите в руках, попала ко мне как рецензенту еще до выхода в свет. Даже в черновом варианте она оказалась превосходной. Дэйву Томасу и Энди Ханту есть что сказать, и они знают, как сказать. Я видел то, над чем они трудились, и уверен, что сделанное ими будет работать. Меня попросили написать это предисловие, в котором я объясняю причины своей уверенности.
   В этой книге говорится о способе программирования, которому вы можете последовать. Вполне возможно, что вы даже и не думали, что программирование окажется таким трудным занятием, но дело обстоит именно так. Почему? С одной стороны, не все книги по программированию написаны профессиональными программистами. Многие из них скомпилированы создателями языков программирования или же журналистами, которые сотрудничают с ними в продвижении на рынок этих языков. Книги эти рассказывают вам, как общаться на некоем языке программирования (что, конечно, является немаловажным фактором), но это лишь малая часть того, чем, собственно, занимается программист.
   Что же программист делает помимо общения на языке программирования? Эта проблема достаточно глубока. Большинство программистов затруднились бы объяснить, что же они делают. Программирование – это работа, насыщенная подробностями, и для того чтобы уследить за ними, необходимо сосредоточиться. Проходит время, на свет появляется программа. Если всерьез не задумываться над тем, что вы делали, можно придти к выводу, что программирование сводится к набору операторов на специфическом языке. Разумеется, это неправда, но вы ни за что бы так не подумали, осмотревшись по сторонам в секции программирования книжного магазина.
   В своей книге "Программист-прагматик" Дэйв и Энди рассказывают нам о способе программирования, которому мы можем последовать. Как же им удалось добиться таких успехов? Не сосредоточились ли они на деталях, уподобившись другим программистам? Нет, они лишь уделили внимание тому, что они делали, во время самой работы, а затем попытались сделать это несколько лучше.
   Представьте, что сидите на совещании. Наверное, выдумаете, что совещание длится целую вечность, а вместо него лучше было бы заняться программированием. Дэйв и Энди в такой ситуации думали бы о том, почему происходит это совещание, и задались вопросом, существует ли что-то еще, что они могли бы сделать вместо совещания, и может ли это «что-то» быть автоматизировано таким образом, чтобы это совещание проходило не в настоящем, а в будущем. Затем они бы осуществили задуманное.
   Именно таков образ мышления Дэйва и Энди. Это совещание не отвлекало бы их от программирования. Напротив, это и было бы программирование. И этот способ может быть усовершенствован. Я знаю, что они мыслят именно таким образом, поскольку в книге есть подсказка 2: "Думай! О своей работе".
   Представьте себе, что авторы мыслят подобным образом на протяжении нескольких лет. У них вскоре должна была бы собраться целая коллекция решений. Теперь представьте, что они используют эти решения в своей работе на протяжении еще нескольких лет и при этом отказываются от слишком трудных решений или тех, что не всегда приводят к желаемому результату. Этот подход и может быть определен как прагматический. Вы, вероятно, подумаете, что подобная информация – настоящая золотая жила. И будете правы.
   Авторы рассказывают нам, как они программируют. И рассказывают тем способом, которому мы можем последовать. Но в последнем утверждении есть нечто большее, чем вы думаете. Позвольте мне объяснить.
   Авторы проявили осторожность, избегая выдвижения теории разработки программного обеспечения. Это хорошо, поскольку в противном случае им пришлось бы исказить всю книгу, защищая эту теорию. Подобное искажение является традицией в физике, где теории в конечном счете становятся законами или же преспокойно отвергаются. С другой стороны, программирование подчиняется немногим (если вообще каким-нибудь) законам. Поэтому совет в области программирования, вращающегося вокруг квазизаконов, может прекрасно выглядеть в теории, но на практике не провалиться. Именно это происходит со многим книгами по методологии.
   Я изучал эту проблему в течение десяти лет и обнаружил, что самым многообещающим является подход, называемый языком шаблонов. Вкратце шаблон представляет собой некое решение, а язык шаблонов является некой системой решений, подкрепляющих друг друга. Вокруг поиска таких систем сформировалось целое сообщество.
   Эта книга – нечто большее, чем просто собрание подсказок. Это и есть язык шаблонов, но в "овечьей шкуре". Я говорю так потому, что каждая подсказка получена из реального опыта, подана как конкретный совет и соотносится с другими, образуя систему. Подсказки представляют собой характеристики, которые позволяют нам изучать язык шаблонов и следовать ему.
   Вы можете следовать советам, содержащимся в данной книге, потому что они конкретны. В книге нет расплывчатых абстракций. Дэйв и Энди пишут непосредственно для вас, так, как будто каждая подсказка является жизненно необходимой для пробуждения вашей карьеры в сфере программирования. Они упрощают эту сферу, они рассказывают некую историю, используют легкие намеки, а затем отвечают на вопросы, возникающие, когда вы попробуете сделать что-либо.
   Есть и нечто большее. После того как вы прочтете десять или пятнадцать подсказок, вам начнет открываться новое измерение вашей работы. В английском языке это измерение обозначается аббревиатурой QWAN (Quality Without A Name – качество без имени). Книга содержит философию, которая будет внедряться в ваше сознание и смешиваться с вашей собственной. Она не занимается проповедью. Она лишь сообщает, что может работать. Но рассказ способствует проникновению внутрь. В этом состоит красота этой книги: она воплощает философию и делает это непретенциозно.
   И вот она перед вами – простая в чтении и применении книга о практике программирования. Я все говорю и говорю о том, почему она действенна. Вам же, вероятно, нужно, чтобы она действовала в принципе. Она действует. Вы это увидите вами.
    Уорд Каннингхэм

Кому адресована эта книга?

Как происходит становление программиста-прагматика?

Прагматики-одиночки и большие команды

Непрерывность процесса

Как составлена эта книга

Исходные тексты программ и другие ресурсы

Ваши отклики

Благодарности

1
Мой исходный текст съел кот Мурзик

2
Энтропия в программах

3
Суп из камней и сварившиеся лягушки

4
Приемлемые программы

5
Портфель знаний

6
Общайтесь!

7
Пороки дублирования

8
Ортогональность

9
Обратимость

10
Стрельба трассирующими

11
Прототипы и памятные записки

12
Языки, отражающие специфику предметной области

13
Оценка

14
Преимущества простого текста

15
Игры с оболочками

16
Мощь редактирования

17
Управление исходным текстом программ

18
Отладка

19
Обработка текста

20
Генераторы текстов программ

21
Проектирование по контракту

22
Мертвые программы не лгут

23
Программирование утверждений

24
Случаи, в которых используются исключения

25
Балансировка ресурсов

26
Несвязанность и закон Деметера

27
Метапрограммирование

28
Временное связывание

29
Всего лишь визуальное представление

30
Доски объявлений

31
Программирование в расчете на стечение обстоятельств

32
Скорость алгоритма

33
Реорганизация

34
Программа, которую легко тестировать

35
Злые волшебники

36
Карьер для добычи требований

37
Разгадка невероятных головоломок

38
Чувство готовности

39
Западня со стороны требований

40
Круги и стрелки

41
Команды прагматиков

42
Вездесущая автоматизация

43
Безжалостное тестирование

44
Все эти сочинения

45
Большие надежды

46
Гордость и предубеждение

Профессиональные общества

Собираем библиотеку

Интернет-ресурсы

   [Bak72] F.T. Baker. Chief programmer team management of production programming. IBM Systems Journal, 1 1(1 ):56—73, 1972.
   [BBM96] V. Basili, L. Brand, and W.L. Melo. A validation of object-oriented design metrics as quality indicators. IEEE Transactions on Software Engineering, 22(10):751-761, October 1996.
   [Ber96] Albert J. Bernstein. Dinosaur Brains: Dealing with All Those Impossible People at Work. Ballantine Books, New York, NY, 1996.
   [Bra95] Marshall Brain. Win32 System Services. Prentice Hall, Englewood Cliffs, NJ, 1995.
   [Bro95] Frederick P. Brooks, Jr.. The Mythical Man Month: Essays on Software Engineering. Addison -Wesley, Reading, MA, anniversary edition, 1995.
   [CG90] N. Carriero and D. Gelenter. How to Write Parallel Programs: A First Course. MIT Press, Cambridge, MA, 1990.
   [CN91] Brad J. Cox and Andrex J. Novobilski. Object-Oriented Programming, An Evolutionary Approach. Addison-Wesley, Reading, MA, 1991.
   [Coc97a] Alistair Cockburn. Goals and use cases. Journal of Object Oriented Programming, 9(7):35-40, September 1997.
   [Coc97b] Alistair Cockburn. Surviving Object-Oriented Projects: A Manager's Guide. Addison Wesley Longman, Reading, MA, 1997.
   [Cop92] James O. Coplien. Advanced С++ Programming Styles and Idioms. Addison-Wesley, Reading, MA, 1992.
   [DL99] Tom Demarco and Timothy Lister. Peopleware: Productive Projects and Teams, Dorset House, New York, NY, second edition, 1999.
   [FBB+99] Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts. Refactoring: Improving the Design of Existing Code. Addison Wesley Longman, Reading, MA, 1999
   [Fow96] Martin Fowler. Analysis Patterns: Reusable Object Models. Addison Wesley Longman, Reading, MA, 1996.
   [FS97] Martin Fowler and Kendall Scott. UML Distilled: Applying the Standard Object Modeling Language. Addison Wesley Longman, Reading, MA, 1997.
   [GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995.
   [Gla99a] Robert L. Glass. Inspections – Some surprising findings. Communications of the ACM, 42(4): 17–19, April 1999.
   [Gla99b] Robert L. Glass. The realities of software technology payoffs. Communications of the ACM, 42(2):74–79, February 1999.
   [Hol78] Michael Holt. Math Puzzles and Games, Dorset Press, New York, NY, 1978.
   [Jac94] Ivar Jacobson. Object-Oriented Software Engineering: A Use-Case Driven Approach. Addison-Wesley, Reading, MA, 1994.
   [KLM+97] Gregor Kiczales, John Lamping, AnuragMendhekar, Chris Maeda, Cris-tina Videira Lopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming. In European Conference on Object-Oriented Programming (ECOOP), volume LNCS 1241. Springer-Verlag, June 1997.
   [Knu97a] Donald Ervin Knuth. The Art of Computer Programming: Fundamental Algorithms, volume 1. Addison Wesley Longman, Reading, MA, third edition, 1997.
   [Knu97b] Donald Ervin Knuth. The Art of Computer Programming: Seminumeri-cal Algorithms, volume 2. Addison Wesley Longman, Reading, MA, third edition, 1997.
   [Knu98] Donald Ervin Knuth. The Art of Computer Programming: Sorting and Searching, volume 3. Addison Wesley Longman, Reading, MA, second edition 1998.
   [KP99] Brian W. Kernighan and Rob Pike. The Practice of Programming. Addison Wesley Longman, Reading, MA, 1999.
   [Kru98] Philippe Kruchten. The Rational Unified Process: An Introduction. Addison Wesley Longman, Reading, MA, 1998.
   [Lak96] John Lakos. Large-Scale С++Software Design. Addison Wesley Longman, Reading, MA, 1996.
   [LH89] Karl J. Lieberherr and Ian Holland. Assuring good style for object-oriented programs. IEEE Software, pages 38–48, September 1989.
   [Lis88] Barbara Liskov. Data abstraction and hierarchy. SIGPLAN Notices, 23(5), May 1988.
   [LMB92] John R. Levine, Tony Mason, and Doug Brown. Lex and Yacc. O'Reilly & Associates, Inc., Sebastopol, CA, second edition, 1992.
   [McC95] Jim McCarthy. Dynamics of Software Development. Microsoft Press, Redmond, WA, 1995.
   [Mey96] Scott Meyers. More Effective С++: 35 New Ways to Improve Your Programs and Designs. Addison-Wesley, Reading, MA, 1996.
   [Mey97a] Scott Meyers. Effective С++: 50 Specific Ways to Improve Your Programs and Designs. Addison Wesley Longman, Reading, MA, 1997.
   [Mey97b] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, Englewood Cliffs, NJ, second edition, 1997.
   [Pet 98] Charles Petzold. Programming Windows, The Definitive Guide to the Win32 API. Microsoft Press, Redmond, WA, fifth edition, 1998.
   [Sch95] Bruce Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C. John Wiley & Sons, New York, NY, 1995.
   [Sed83] Robert Sedgewick. Algorithms. Addison-Wesley, Reading, MA, 1983.
   [Sed 92] Robert Sedgewick. Algorithms in С++. Addison-Wesley, Reading, MA, 1992.
   [SF96] Robert Sedgewick and Phillipc Flajolet. An Introduction to the Analysis of Algorithms. Addison-Wesley, Reading, MA, 1996.
   [Ste92] W. Richard Stevens. Advanced Programming in the Unix Environment. Addison-Wesley, Reading, MA, 1992.
   [Ste98] W. Richard Stevens. Unix Network Programming, Volume I: Networking APIs: Sockets andXti. Prentice Hall, Englewood Cliffs, NJ, 1998.
   [Ste99] W. Richard Stevens. Unix Network Programming, Volume 2: Interprocess Communications. Prentice Hall, Englewood Cliffs, NJ, second edition, 1999.
   [Str35] James Ridley Stroop. Studies of interference in serial verbal reactions. Journal of Experimental Psychology, 18:643–662, 1935.
   [WK82] James Q. Wilson and George Kelling. The police and neighborhood safety. The Atlantic Monthly, 249(3):29–38, March 1982.
   [YC86] Edward Yourdon and Larry L. Constantine. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Prentice Hall, Englewood Cliffs, NJ, second edition, 1986.
   [You95] Edward Yourdon. Managing projects to produce good-enough software. IEEE Software, March 1995.

Упражнение 1 из раздела "Ортогональность"

   Ответ: По нашему разумению, более ортогональным является класс Split2. Он сосредоточен на собственной задаче – расщеплении строк и игнорирует подробности, связанные с источником обрабатываемых им строк. Это не только упрощает разработку программы, но и придает ей большую гибкость. Класс Split2 может расщеплять строки, считываемые из файла, сгенерированные другой программой или передаваемые через операционную среду.

Упражнение 2 из раздела "Ортогональность"

   Ответ: Если все сделано корректно, то, по всей вероятности, немодальное. Система, которая использует немодальные диалоговые окна, испытывает меньшее беспокойство о том, что происходит в любой конкретный момент времени. Скорее всего, она будет обладать лучшей инфрастуктурой взаимодействия между модулями по сравнению с модальной системой, которая может содержать встроенные предположения о состоянии системы – предположения, которые могут привести к большему связыванию и уменьшению ортогональности.

Упражнение 3 из раздела "Ортогональность"

   Ответ: Здесь есть элемент лукавства. Объектная технология может обеспечить наличие более ортогональной системы, но поскольку она имеет больше средств, которые могут эксплуатироваться с нарушением режима, в реальности легче создать неортогональную систему, используя объекты, чем создавать ее при помощи процедурного языка. Ее особенности – множественное наследование, исключительные ситуации, перегрузка операторов и переопределение родительского метода (через механизм подклассов) – предоставляют достаточные возможности для увеличения связанности не столь очевидными способами.
   Применяя объектную технологию и приложив небольшое дополнительное усилие, вы можете добиться наличия более ортогональной системы. И хотя вы всегда можете написать неструктурированную программу на процедурном языке, объектно-ориентированные языки, используемые в малых дозах, могут сделать ее более насыщенной.

Упражнение 4 из раздела "Прототипы и памятные записки"

   Ответ: Для спасения ситуации прибегнем к устаревшим технологиям! Нарисуйте на лекционной доске несколько картинок – автомобиль, телефон и дом – с помощью фломастера. Для этого не нужно быть великим художником, вполне достаточно условных изображений. Поместите на доску памятные записки, описывающие содержимое целевых страниц в активных областях экрана. В ходе встречи вы можете совершенствовать рисунки и менять расположение памятных записок.

Упражнение 5 из раздела "Языки, отражающие специфику предметной области"

   Ответ: Поскольку мы хотим, чтобы язык был расширяемым, сделаем таблицу синтаксического анализатора управляемой. Каждый элемент таблицы содержит символ команды, флаг, говорящий о необходимости аргумента, и имя подпрограммы, вызываемой для обработки этой конкретной команды.
   typedef struct {
   char cmd; /* the command letter */
   int hasArg; /* does it take an argument */
   void (*func)(int, int); /* routine to call */
   } Command;
   static Command cmds[] = {
   {'P', ARG, doSelectPen},
   ('V', NO_ARG, doPenUp},
   {'D', NO_ARG, doPenDown},
   {'N,' ARG, doPenDir},
   {'E', ARG, doPenDir},
   {'S', ARG, doPenDir},
   {'W', ARG, doPenDir}
   };
   Основная программа довольно проста: считать строку, отыскать команду, при необходимости принять аргумент, затем вызвать функцию обработчика.
   while (fgetsfbuff, sizeof(buff), stdin)) {
   Command *cmd = findCommand(*buff);
   if (cmd) {
     int arg = 0;
     if (cmd->hasAr&& !getArg(buff+1, &arg)) {
        fprintf(stderr,"'%с' needs an argument\n", *buff);
        continue;
     }
   cmd->func(*buff, arg);
   }
   }
   Функция, которая ищет команду, исполняет последовательный перебор таблицы, возвращая либо совпадающий элемент, либо NULL.
   Command *findCommand(int cmd) {
   int i;
   for (i = 0; i<ARRAY.SIZE(cmds); i++) {
     if (cmds[i].cmd==cmd)
       return cmds + i;
     }
   fprintf(stderr, "Unknown command %c'\n", cmd);
   return 0;
   }
   И наконец, считывание числового аргумента довольно просто, если использовать подпрограмму sscanf.
   int getArg(const char *buff, int 'result) {
      return sscanf(buff, "%d", result) == 1;
   }

Упражнение 6 из раздела "Языки, отражающие специфику предметной области"

   Ответ 6: При использовании BNF спецификация времени могла бы выглядеть следующим образом:
   <tlme>::= <hour> <ampm> |
           <hour>: <minute> <ampm> |
           <hour>: <minute>
   <ampm>::= am|pm
   <hour>::=<digit> |
           <digit>::=<digit>
   <mlnute>::=<digit><digit>
   <digit>::= 0|1|2|3|4|5|6|7|8|9

Упражнение 7 из раздела "Языки, отражающие специфику предметной области"

   Ответ: В нашем примере мы составили программу, используя генератор bison, который представляет собой GNU-версию генератора уасс. Для ясности здесь показано только тело программы синтаксического анализатора. Полная версия есть на сайте www.pragmaticprogrammmer.com.
   time: spec EOF
   { if ($1>= 24*60) yyerror("Time is too large");
      printf("%d minutes past midnight\n", $1);
      exit(0);
   }
   ;
   spec:  hour ':' minute
       { $$ = $1 + $3;
       }
     | hour ':' minute ampm
   { if ($1>11*60) yyerrorf "Hour out of range");
      $$ = $1 + $3 + $4;
   }
   | hour ampm
     {if ($1>11*60) yyerror("Hour out of range");
       $$ = $1 + $2;
      }
   ;
   hour: hour_num
       {if ($1>23) yyerror("Hour out of range");
        $$ = $1 * 60;
       };
   minute: DIGIT DIGIT
        {$$ = $1*10 + $2;
        if ($$> 59) yyerrorf "minute out of range") ,
        };
   ampm: AM {$$ = AM_MINS;}
       |      PM {$$ = PM_MINS;)
       ;
   hour num:  DIGIT {$$ = $1;)
       | DIGIT DIGIT {$$ = $1*10 + $2;}
       ;

Упражнение 8 из раздела "Языки, отражающие специфику предметной области"

   Ответ:
   $_ = shift;
   /"(\d\d?)(am|pm)$/ && doTime($1, 0, $2, 12);
   /"(\d\d?):(\d\d)(am|pm)$/ && doTime($1, $2, $3, 12);
   /"(\d\d?):(\d\d)$/ && doTime($1, $2, 0, 24);
   die "Invalid time $_\n";
   #
   # doTime(hour, min, ampm, maxHour)
   #
   sub doTime($$$$) {
   my ($hour, $min, $offset, $maxHour) = @_;
   die "Invalid hour: $hour" if ($hour>= $maxHour);
   $hour += 12 if ($offset eq "pm")
   print $hour*60 + $min, " minutes past midnight\n";
   exit(0);
   }

Упражнение 9: из раздела "Оценка"

   Ответ: Ответ должен быть изложен, исходя из нескольких допущений:
   • Лента содержит информацию, которую необходимо передать.
   • Известна скорость ходьбы человека.
   • Известно расстояние между компьютерами.
   • Временем, необходимым для переноса информации на ленту и с ленты, можно пренебречь.
   • Потери данных при хранении на ленте примерно равны их потерям при передаче по каналу связи.

Упражнение 10 из раздела "Оценка"

   Ответ: Учитывая допущения ответа 9: Объем информации, содержащейся на стриммерной кассете (4 Гбайт), составляет 32 х 10^9 бит, так что передача эквивалентного объема по каналу со скоростью 1 Мбайт/с заняла бы около 32000 сек. (примерно 9 ч). Если человек движется с постоянной скоростью 3,5 мили в час, то, для того чтобы канал связи превзошел курьера, два компьютера должны располагаться друг от друга на расстоянии не менее 31 мили. Если это расстояние меньше, то победа остается за человеком.

Упражнение 11 из раздела "Обработка текста"

   Ответ: Ответ к данному упражнению составлен на языке Perl.
   my @consts;
   my $name = <>;
   die "Invalid format – missing name" unless defined($name);
   chomp $name;
   # Read in the rest of the file
   while (<>) {
     chomp;
     s/"\s*//; s/\s*$//;
     die "Invalid line: $_" unless /"(\w+)$/;
     push @consts, $_;
   }
   # Now generate the file
   open(HDR, ">$name.h") or die "Can't open $name.h: $!";
   open(SRC, ">$name.c") or die "Can't open $name.c: $!";
   my $uc_name = uc($name);
   print HDR "/* File generated automatically – do not edit */\n";
   print HDR "extern const char *$ {ucjiame)_name[];";
   print HDR "typedef enum {\n"; print HDR join",\n", @consts;
   print HDR "\n) $uc_name;\n\n";
   print SRC "* File generated automatically – do not edit */\n";
   print SRC "const char *$ {uc name}_name[] = {\n \"";
   print SRC join "\",\n \"", @consts;
   print SRC "\"\n};\n";
   close(SRC);
   close(HDR);
   Используя принцип DRY, мы не будет вырезать и вклеивать этот вновь написанный файл в нашу программу. Вместо этого мы «включим» его – данный плоский файл является главным источником этих констант. Поэтому нам понадобится файл сборки для восстановления заголовка при изменении файла. Следующий фрагмент содержится в системе отладки в исходном дереве (имеется на web-сайте).
   etest.c etest.h: etest.inc enumerated.pl
                  perl enumerated.pl etest.inc
 

Упражнение 12 из раздела "Обработка текста"

   Ответ: Вот ответ, написанный на языке Perl.
   my $dir = shift or die "Missing directory" ,
   for my Sfile (glob(u$dir/*.pr)) {
   open(IP, "$file") or die "Opening $file: $!";
   undef $/; # Turn off input record separator -
   my Scontent = <IP>; # read whole file as one string.
   close(IP);
   if (Scontent Гrusestrict/m) {
   rename Sfile, "$file.bak" or die "Renaming $file: $!"; open(OP, ">$file") or die "Creating $file: $!";
   # Put 'use strict' on first line that
   # doesn't start #
   Scontent =" sr(V.#)/\nuse strict;\n\n/m',
   print OP Scontent; close(OP);
   print "Updated $file\n";
   )
   else {
   print "Sfile already strict\n":
   )
   }

Упражнение 13 из раздела "Генераторы исходных текстов"

   Ответ: Решение реализовано на языке Perl. В программе происходит динамическая загрузка модуля для генерации требуемого языка, так что добавление новых языков не представляет труда. Главная программа загружает внутреннюю часть (основанную на параметре командной строки), затем считывает ее входные данные и вызывает подпрограммы генерации текста, основанные на содержимом каждой из строк. Мы особенно не суетимся, если речь идет об обработке ошибок: если что-то не так, узнаем об этом довольно быстро.
   my lang = shift or die "Missing language";
   $lang .= "_cg.pm";
   require <$lang> or die "Couldn't load $lang";
   # Read and parse the file
   my $name;
   while (<>) {
     chomp;
   if (/^ \s*$/)   {CG::blankLine();)
   elsif ((/^ \#(.*)/)   {CG::comment($1);}
   elsif ((/^M\s*(.+)/)   {CG::startMsg($1); $name = $1;}
   elsif ((/^E/)    {CG::endMsg($name);}
   elsif (/^F\s*(\w+)\s+(\w+)$/) {CG::simpleType($1,$2);}
   elsif (/^F\s*(\w+)\s+(\w+)\[(\d+)\]$/) {CG::arrayType $1,$2,$3);}
   else {
   die "Invalid line: $ ";
   }
   }
   Написание языковой серверной части не составит труда: создайте модуль, который реализует шесть точек входа. Вот генератор текста на языке С:
   #!/usr/bin/perl – w
   package CG;
   use strict;
   # Code generator for 'C' (see cg_base.pl)
   sub blankLine()  {print "\n"; }
   sub comment()  {print "/*$_[0] */\n"; }
   sub startMsg()   {print "typedef struct {\n"; }
   sub endMsg()    {print "} $_[0];\n\n"; }
   sub arrayType() {
     my ($name, $type, $size) = @_;
     print " $type $name\[$size];\n":
   }
   sub simpleType{) {
     my ($name, $type) = @_;
     print " $type $пате;\п";
   }
   1;
 
   А вот генератор текста на языке Pascal:
   #!/usr/bin/perl – w
   package CG;
   use strict;
   # Code generator for 'Pascal' (see cg_base.pl)
   sub blankLine() {print "V;)
   sub comment() {print "{$_[0] }\n";)
   sub startMsg()  {print "$_[0] = packed record\n"; }
   sub endMsg()   {print "end;\n\n"; }
   sub arrayType() {
     my ($name, $type, $size) = @_;
     $size--;
     print" $name: array[0…$size] of $type;\n";
   )
   sub simpleType() {
     my ($name, $type) = @_;
     print" $name: $type;\n7 ',
   }
   1;
 

Упражнение 14 из раздела "Проектирование по контракту"

   Ответ: Этот пример на языке Eiffel удачен. Мы требуем передачи непустых данных и гарантируем, что семантика циклического двунаправленного списка будет соблюдена. Это также способствует нахождению сохраненной строки. Поскольку это некий отложенный класс, то действительный класс, его реализующий, допускает использование любого основного механизма по своему усмотрению. Он может использовать указатели или массив, или что-то еще; пока он соблюдает контракт, мы не беспокоимся.

Упражнение 15 из раздела "Проектирование по контракту"

   Ответ: Это неудачно. Математическое действие в индексном выражении (index-1) не будет работать с граничными условиями, подобными первой точке входа. Постусловие предполагает определенную реализацию; контракты должны быть более абстрактными по сравнению с указанным выше.

Упражнение 16 из раздела "Проектирование по контракту"

   Ответ 16: Это удачный контракт, но неудачная реализация. Здесь высовывает свою уродливую голову ошибка типа "Heisenbug" [URL52]. Вероятно, программист допустил опечатку – набрал pop вместо top. Хотя это простой и надуманный пример, весьма трудно диагностировать побочные эффекты в утверждениях (или в любом, самом неожиданном месте в программе).

Упражнение 17 из раздела "Проектирование по контракту"

   Ответ: Мы продемонстрируем функциональные сигнатуры на языке Java, обозначая предусловия и постусловия в соответствии с iContract. Сначала инвариант для класса:
   /**
   * @invariant getSpeed() >0
   * implies isFull() // Не запускать пустое
   * @invariant getSpeed()>=0 &&
   * getSpeed() <10 // Проверка границ
   */
   Затем предусловия и постусловия:
   /**
   * @pre Math.abs(getSpeed() – х) <= 1 // Единственный выбор
   * @рге х>= 0 &&  х > 10  // Проверка границ
   * @post getSpeed() == х    // Проверка скорости
   */
   public void setSpeed (final int x)
   /**
   * @pre !isFull()  // Heзаполнять дважды
   * @post isFull() // Убедитесь, что было выполнено
   */
   void fill()
   /**
   * @pre isFull()    // He очищатьдважды
   * @post !isFull() // Убедиться, что выполнено
   */
   void empty()
 

Упражнение 18 из раздела "Проектирование по контракту"

   Ответ: В этом ряду содержится 21 число. Если вы ответили «20», то допустили так называемую ошибку "поста охраны".

Упражнение 19 из раздела "Программирование утверждений"

   Ответ:
   1. В сентябре 1752 г. было всего лишь 19 дней. Это было сделано с целью синхронизации при переходе с юлианского на григорианский календарь.
   2. Каталог мог быть удален другим процессом, у вас нет прав доступа на его чтение, выражение &sb может быть недопустимым – вы все уловили.
   3. Мы проявили малодушие, не указав типов а и b. Во время перегрузки операторов могло случиться так, что поведение знаков +, =, или != стало непредсказуемым. Кроме того, а и b могут быть псевдонимами одной и той же переменной, так что при втором присвоении произойдет перезапись значения, сохраненного во время первого.
   4. В неевклидовой геометрии сумма углов треугольника не будет составлять 180°. Подумайте о треугольнике, отображаемом на поверхности сферы.
   5. Минуты, приходящиеся на високосный год, могут состоять из 61 или 62 секунд.
   6. Переполнение может оставить результат операции а+1 отрицательным (это также может произойти в языках С и С++).

Упражнение 20 из раздела "Программирование утверждений"

   Ответ: Мы решили реализовать очень простой класс с единственным статическим методом TEST, который выводит на печать сообщение и след стека, если переданный параметр condition является ложным.
   package com.pragprog.util;
   import java.lang.System; //для exit()
   import java.lang.Thread; //для dumpStack()
   public class Assert {
   /** Write a message, print a stack trace and exit if
      * our parameter is false.
      */
   public static void TEST(boolean condition) {
     if (Icondition) {
       System.out.println("==Assertion Failed==");
       Thread.dumpStack();
        System.exit(1);
      }
   }
   // Testbed. If our argument is 'okay', try an assertion that
   // succeeds, if 'fail' try one that fails
   public static final void main(String args[]) {
   if (args[0].compareTo("okay") == 0) {
      TEST(1 == 1);
   }
   else if (args[0].compareTo("fail") == 0) {
      TEST(1 == 2);
   }
   else {
     throw new RuntimeException("Bad argument") ,
     }
    }
   }

Упражнение 21 из раздела "Случаи, когда используются исключения"

   Ответ: Нехватка памяти является исключительным состоянием, поэтому мы полагаем, что в случае (1) должно возбуждаться исключение.
   Невозможность отыскания точки входа – вполне нормальная ситуация. Приложение, которое вызывает наш класс-набор, может написать программу, которая проверяет наличие точки входа, перед тем как добавить потенциальный дубликат. Мы полагаем, что в случае (2) нужно просто осуществить возврат ошибки.
   Случай (3) более проблематичен – если указатель null играет существенную роль в приложении, его добавление к контейнеру может быть оправдано. Но если для хранения пустых значений нет веских оснований, то, по всей вероятности, необходимо возбудить исключительную ситуацию.

Упражнение 22 из раздела "Балансировка ресурсов"

   Ответ: В большинстве реализаций языков С и С++ отсутствуют способы проверки того, что указатель действительно указывает на допустимый блок памяти. Обычная ошибка состоит в освобождении блока памяти и организации ссылки на этот блок далее в тексте программы. К тому времени этот блок памяти уже может быть перераспределен для других целей. Обнуляя указатель, программисты надеются предотвращать эти инородные ссылки – в большинстве случаев разыменование указателя null генерирует ошибку в ходе выполнения программы.

Упражнение 23 из раздела "Балансировка ресурсов"

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

Упражнение 24 из раздела "Несвязанность и закон Деметера"

   Ответ: Файл заголовка предназначен для определения интерфейса между соответствующей реализацией и внешним миром. Сам по себе файл заголовка не обязан обладать информацией о внутренней организации класса Date – от него лишь требуется сообщить компилятору о том, что конструктор принимает класс Date в качестве параметра. Поэтому, если файл заголовка не использует Dates в подставляемых функциях, второй фрагмент будет работать просто замечательно.
   А что же с первым фрагментом? Если он используется в небольшом проекте, то все нормально, за исключением того, что вы без особой надобности заставляете все элементы программы, которые используют класс Person1, также включать файл заголовка для класса Date. Как только подобное употребление становится обычной практикой в неком проекте, вскоре обнаружите, что включение одного файла заголовка заканчивается включением большей части системы, что существенно увеличивает время компиляции.

Упражнение 25 из раздела "Несвязанность и закон Деметера"

   Ответ: Переменная acct передается в виде параметра, так что вызов getBalance является допустимым. Вызов amt.printFormat() таковым не является. Мы не «владеем» amt, и он не был передан нам. Мы могли устранить связывание showBalance с Money при помощи вставки, подобной представленной ниже:
   void showBalance(BankAccount b) {
       b.printBalance();
   }

Упражнение 26 из раздела "Несвязанность и закон Деметера"

   Ответ: Поскольку класс Colada создает и владеет myBlender и myStuff, то обращения к addlngredients и elements являются допустимыми.

Упражнение 27 из раздела "Несвязанность и закон Деметера"

   Ответ: В этом случае processTransaction владеет amt – он создается на стеке. Происходит передача acct, поэтому допустимыми являются как setValue, так и setBalance. Но processTransaction не владеет who, поэтому вызов who->name() является нарушением. Закон Деметера предлагает заменить эту строку на следующую:
   markWorkflow(acct.name (), SET_BALANCE);
   Программе в processTransaction не придется узнавать, какой дочерний объект в пределах BankAccount носит это имя – эта информация о структуре не должна разглашаться через контракт BankAccount. Вместо этого мы запрашиваем у BankAccount имя на счете. Он знает, где хранится имя (может быть, в объекте Person, в объекте Business, или в полиморфном объекте Customer).

Упражнение 28 из раздела "Метапрограммирование"

   Ответ: Здесь не приводятся категорические ответы – вопросы предназначались в основном для того, чтобы дать вам пищу для размышлений. И вот что мы думаем:
   1. Назначения коммуникационного порта. Ясно, что эта информация должна сохраняться в виде метаданных. Но на каком уровне детализации? Некоторые коммуникационные программы системы Windows позволяют выбирать только скорость в бодах и порт (скажем, СОМ1 – COM4). Но вероятно вам придется указать размер слова, четность, стоповые биты, и настройку дуплексной связи. Старайтесь допускать самый мелкий уровень детализации, там где это разумно с практической точки зрения.
   2. Поддержка выделения синтаксических конструкций различных языков в программе редактирования. Она должна быть реализована в виде метаданных. Вы же не хотите, чтобы вам пришлось переделывать программу только потому, что в последней версии языка Java было введено новое ключевое слово.
   3. Поддержка редактора для различных графических устройств. Эту поддержку было бы трудно реализовать исключительно в виде метаданных. Вам не хотелось бы нагружать приложение многими драйверами устройств только для того, чтобы выбрать один из них во время выполнения программы. Однако вы могли воспользоваться метаданными для указания имени драйвера и динамической загрузки программы. Это еще один аргумент для сохранении метаданных в удобочитаемом формате; если вы используете программу для установки дисфункционального видеодрайвера, то вы не сможете переустановить его, пользуясь этой программой.
   4. Конечный автомат для программы синтаксического анализа или сканера.
   Это зависит от того, анализируете вы или просматриваете. Если анализируете некоторые данные, которые жестко определены в стандартах и скорее всего не будут изменены без одобрения конгресса США, то жесткое кодирование вполне годится. Но если вы сталкиваетесь с более изменчивой ситуацией, то может быть, более выгодным является внешнее определение таблиц состояний.
   5. Типовые значения и результаты, используемые в модульном тестировании.
   Большинство приложений определяет эти значения как встроенные в тестовый стенд, но вы можете добиться большей гибкости, перемещая тестовые данные и определение приемлемых результатов за пределы самой программы.

Упражнение 29 из раздела "Всего лишь представление"

   Ответ: В программу Flight мы добавим ряд дополнительных методов душ поддержания двух списков «слушателей»: для уведомления о листе ожидания и о полной загрузке рейса.
   public interface Passenger {
     public void waitListAvailable();
   }
   public interface Flight {
   ...
     public void addWaitListListener(Passenger p);
     public void removeWaitUstUstener(Passenger p);
     public void addFullListener(FullListener b);
     public void removeFullListener(FullListener b);
   ...
   }
   public interface BigReport extends FullListener {
     public void FlightFullAlert(Flight f);
   }
   При неудачной попытке добавить Passenger, поскольку рейс полностью забронирован, мы можем (как вариант) поместить Passenger в лист ожидания. При открытии вакансии производится вызов метода waitListAvailable. Затем этот метод может осуществить выбор: либо добавить Passenger автоматически, либо дать указание сотруднику авиакомпании позвонить заказчику и выяснить, заинтересован ли он еще в рейсе, и т. п. Теперь мы обладаем достаточной гибкостью, чтобы избрать линию поведения, исходя из пожеланий клиента.
   Кроме того, мы хотим избежать ситуаций, при которых BigReport разбирает тонны записей, отыскивая полностью забронированные рейсы. Зарегистрировав BigReport в качестве «слушателя» Flights, каждый индивидуальный Flight может сообщать, когда он полностью (или почти полностью) забронирован. Теперь пользователи могут мгновенно получить оперативные, с точностью до минуты, сообщения из BigReport, а не ожидать часами окончания его работы, как это было раньше.

Упражнение 30 из раздела "Доски объявлений"

    Ответ:
   1.  Обработка изображения.Для простого распределения рабочей нагрузки между параллельными процессами более чем адекватной может оказаться общедоступная очередь работ. Вы можете рассмотреть систему "доска объявлений" при наличии обратной связи, т. е. если результаты обработки одного фрагмента изображения влияют на другие фрагменты так, как это происходит в системах искусственного зрения или сложных трехмерных преобразованиях изображений.
   2.  Календарное планирование для групп.Для этого "доска объявлений" очень даже пригодится. Вы можете поместить назначенные собрания и готовность на "доску объявлений". Есть объекты, функционирующие автономно; в данном случае очень важна обратная связь, а участники могут приходить и уходить.
   Можно рассмотреть возможность разделения "доски объявлений" в зависимости от того, кто осуществляет поиск: младший персонал может заботиться только о локальном офисе, отдел кадров интересоваться только англо-говорящими офисами во всем мире, а исполнительный директор – всем сразу.
   В форматах данных имеется некий элемент гибкости: мы можем проигнорировать форматы или языки, которых не понимаем. Нам придется понимать различные форматы только для тех офисов, которые встречаются друг с другом, и не придется подвергать всех участников полному транзитивному замыканию всевозможных форматов. При этом связанность уменьшается там, где нужно, и мы не имеем искусственных ограничений.
   3.  Средство мониторинга компьютерной сети.Это весьма сходно с программой обработки заявлений на ипотечный кредит/ссуду, описанной в примере приложения (с. 153). На доску помещаются сообщения о неисправностях, присылаемые пользователями, и автоматические генерируемые статистические данные. Сотрудник (или программный агент) может анализировать "доску объявлений", чтобы осуществлять диагностику неисправностей в сети: две ошибки в линии могут быть отнесены на счет космических лучей, но 20000 ошибок говорят о проблеме в аппаратном обеспечении. Подобно детективам, разгадывающим тайну убийства, вы можете использовать множественные объекты, анализируя и внося свою лепту в решение проблем, связанных с компьютерной сетью.

Упражнение 31 из раздела "Программирование в расчете на стечение обстоятельств"

   Ответ: Эта программа представляет ряд потенциальных проблем. Во-первых, она предлагает наличие текстовой среды. Это, может быть, и прекрасно, если предположение истинно, но что, если эта программа вызывается из графической среды, где не открыты ни stderr, ни stdin?
   Во-вторых, есть проблематичный оператор gets, который будет записывать столько символов, сколько он получит в переданный буфер. Злонамеренные пользователи использовали это, когда им не удавалось проделать бреши типа buffer overrun в защите многих различных систем. Никогда не пользуйтесь gets().
   В-третьих, программа предполагает, что пользователь понимает английский язык.
   И наконец, никто, находясь в здравом уме, не станет прятать средство взаимодействия с пользователем в недра библиотечной подпрограммы.

Упражнение 32 из раздела "Программирование в расчете на стечение обстоятельств"

   Ответ: Работа программы strcpy в системе POSIX не гарантируется при наличии перекрывающихся строк. С некоторыми архитектурами она, случается, и работает, но лишь при стечении определенных обстоятельств.

Упражнение 33 из раздела "Программирование в расчете на стечение обстоятельств"

   Ответ: Она не будет работать в контексте апплета при наличии ограничений доступа по записи на локальный диск. Если вы можете выбирать, работать ли через графический интерфейс или нет, то, вероятно, захотите осуществить динамический анализ текущей среды. В этом случае вы наверняка захотите поместить файл журнала вне локального диска, если к нему нет доступа.

Упражнение 34 из раздела "Скорость алгоритма"

   Ответ: Ясно, что мы не можем давать никаких абсолютных ответов к этому упражнению. Однако можем дать вам пару намеков.
   Если ваши результаты не ложатся на гладкую кривую, то вы захотите проверить, не используется ли мощность вашего процессора каким-либо другим процессом. По всей вероятности, вы не получите хороших показателей в многопользовательской системе, и даже если окажетесь единственным пользователем, можете заметить, что фоновые процессы периодически отбирают циклы у ваших программ. Вы также можете захотеть проверить использование памяти: если приложение начинает использовать область свопинга, то производительность резко снижается.
   Интересно поэкспериментировать с различными компиляторами и установочными параметрами оптимизации. Мы обнаружили, что весьма впечатляющее ускорение стало возможно, благодаря использованию агрессивной оптимизации. Мы также обнаружили, что на более распространенных архитектурах типа RISC компиляторы фирмы изготовителя часто превосходили по быстродействию более переносимую GCC. Возможно, изготовитель посвящен в тайны эффективной генерации программ на этих машинах.

Упражнение 35 из раздела "Скорость алгоритма"

   Ответ: Программа printTree использует приблизительно 1000 байт стекового пространства для буферной переменной. Для движения вниз по древовидной схеме она рекурсивно вызывает саму себя, и каждый вложенный вызов добавляет еще 1000 байт к стеку. Она также вызывает саму себя, когда добирается до вершин, но заканчивает работу сразу, как только обнаружит, что переданный указатель обнулен. Если глубина дерева равна D, то максимальный объем, необходимый стеку, составляет (грубо) 1000 x(D+ 1).
   Сбалансированное двоичное дерево содержит вдвое больше элементов на каждом уровне. Дерево глубиной D содержит 1+2+4+8 +… +2^(D-1), или 2^D – 1 элементов. Следовательно, дереву, состоящему из миллиона элементов, будет необходимо [lg(1000001], или 20 уровней.
   Поэтому мы рассчитываем, что наша подпрограмма будет использовать примерно 21000 байт стекового пространства.

Упражнение 36 из раздела "Скорость алгоритма"

   Ответ: На ум приходит несколько процедур оптимизации. Программа printTree вызывает саму себя на вершинах дерева лишь для того, чтобы закончить работу при отсутствии потомков. Этот вызов увеличивает максимальную глубину стека примерно на 1000 байт. Можно также исключить рекурсию хвоста (второй рекурсивный вызов), хотя это и не будет затрагивать использование стека в наихудшем случае.
   while (node) {
     if (node->left) printTree(node->left);
     getNodeAsString(node, buffer);
     puts(buffer);
     node = node->right;
   }
   Но самая большая выгода возникает при назначении одного-единственного буфера, доступ к которому осуществляется при всех обращениях к printTree. Если передать этот буфер в виде параметра для рекурсивных обращений, то будет назначено всего 1000 байт вне зависимости от глубины рекурсии.
   void printTreePrivate(const Node *node, char *buffer) {
     if (node) {
       printTreePrivate(node->!eft, buffer);
       getNodeAsStringfnode, buffer);
       puts(buffer);
       printTreePrivate(node->right, buffer);
     }
   }
   void newPrintTree(const Node *node) {
     char buffer[1000];
     printTreePrivate(node, buffer);
   )

Упражнение 37 из раздела "Скорость алгоритма"

   Ответ: Это можно сделать двумя путями. Один из них заключается в том, чтобы перевернуть проблему с ног на голову. Если в массиве есть лишь один элемент, мы не осуществляем итерации в цикле. Каждая дополнительная итерация удваивает размер массива, в котором можно осуществлять поиск. Отсюда общая формула размера массива: n = 2^m, где m – число итераций. Если прологарифмировать обе части с основанием 2, получим выражение lg(n) = lg(2^m), которое из определения логарифма превращается в lg(n) =m.

Упражнение 38 из раздела "Реорганизация"

   Ответ: Здесь мы могли бы предложить весьма умеренную реструктуризацию: убедитесь, что каждый тест выполняется лишь один раз, и сделайте все вычисления стандартными. Если выражение 2*basis (…)* 1.05 появляется в других местах программы, то, вероятно, его стоит сделать функцией. В данном случае мы этого делать не стали.
   Мы добавили массив rate_lookup, инициализированный таким образом, что элементам, отличным от Texas, Ohio и Maine, присвоено значение 1. Этот подход облегчает добавление значений для других штатов в будущем. В зависимости от ожидаемой схемы использования мы могли бы сделать поле points также средством поиска в массиве.
   rate = rate_lookup[state];
   amt = base * rate;
   calc = 2*basis(amt) + extra(amt)*1.05;
   if (state == OHIO)
      points = 2;

Упражнение 39 из раздела "Реорганизация"

   Ответ: Когда вы видите, что кто-либо использует перечислимые типы (или эквивалентные им в языке Java), для того чтобы провести различие между вариантами некоего типа, во многих случаях вы можете улучшить программу за счет создания подклассов:
   public class Shape {
     private double size;
     public Shape(double size) {
        this.size = size;
     }
     public double getSize() {return size;)
   }
   public class Square extends Shape {
     public Square(double size) {
       super(size);
     }
     public double area() {
       double size = getSize();
       return size*size;
     }
   )
   public class Circle extends Shape {
     public Circle(double size) {
       super(size);
     }
     public double area() {
       double size = getSize();
       return Math.PI*size*size/4.0;
     }
   }
   // efc…

Упражнение 40 из раздела "Реорганизация"

   Ответ: Этот случай интересен. На первый взгляд, кажется разумным, что у окна должна быть ширина и высота. Однако стоит подумать о будущем. Представим, что мы хотим обеспечить поддержку окон произвольной формы (что будет весьма трудно, если класс Window обладает всей информацией о прямоугольниках и их свойствах).
   Мы бы предложили абстрагировать форму окна из самого класса Window.
   public abstract class Shape {
   //...
     public abstract boolean overlaps (Shape s);
     public abstract int getArea();
   }
   public class Window {
     private Shape shape;
     public Window(Shape shape)  {
        this.shape = shape;
        ...
   }
   public void setShape(Shape shape) {
      this.shape = shape;
      ...
   }
   public boolean overlaps(Window w) {
      return shape.overlaps(w.shape);
   }
   public int getArea() {
      return shape.getArea();
   }
   }
   Заметим, что в этом подходе мы предпочли делегирование созданию подклассов: окно не является «разновидностью» формы – окно «имеет» форму. Оно использует форму для выполнения своей работы. Вы убедитесь, что во многих случаях делегирование оказывается полезным для реорганизации.
   Мы могли бы расширить этот пример, внедрив интерфейс Java, указывающий на методы, которые должны поддерживаться неким классом для поддержания функций формы. Эта удачная идея означает, что, когда вы расширяете принцип формы, компилятор предупредит вас о классах, которые вы затронули. Мы рекомендуем использовать интерфейсы подобным способом при делегировании всех функций какого-либо другого класса.

Упражнение 41 из раздела "Программа, которую легко тестировать"

   Ответ: Вначале добавим подпрограмму main, которая будет действовать как ведущий элемент модульного тестирования. В качестве аргумента она примет простой мини-язык: <Е> будет означать опорожнение блендера, <F> – его наполнение, цифры 0–9 будут задавать скорость вращения ротора, и т. д.
   public static void main(String args[]) {
   // Create the blender to test
     dbc_ex blender = new dbc_ex();
   // And test it according to the string on standard input
     try {
       int a;
       char c;
       while ((a = System.in.read())!= -1) {
          с = (char)a;
          if (Character.isWhitespace(c)) {
             continue;
          }
          if (Character.is Digit(с)) {
             blender.setSpeed(Character.digit(c, 10));
          }
         else {
            switch (c) {
             case 'F': blender.fi!l();
                          break;
             case 'E': blender.empty();
                          break;
             case 's': System.out.printlnfSPEED: " + blender.getSpeed());
                          break;
             case 'f': System.out.println(<FULL> + blender.isFull());
                          break;
             default: throw new RuntimeException(
                          "Unknown Test directive");
      }
    }
   }
   catch (java.io.lOException e) {
     System.err.println("Tesf jig failed: " + e.getMessage());
   }
   System.err.println("Completed blending\n");
   System.exit(0);
   }
 
   Затем появится сценарий оболочки для управления тестированием.
   #!/bin/sh
   CMD="java dbc.dbc_sx"
   failcount=0
   expect okay() {
     if echo "$*" | $CMD #>/dev/null 2>&1
     then
     ...
     else
        echo "FAILED! $*"
        failcount='expr $failcount + 1'
     fi
   }
   expect_fail() {
   if echo "$*" | SCMD>/dev/null 2> &1
   then
     echo "FAILED! (Should have failed): $*"
      failcount='expr $failcount + 1'
   fi
   }
   report() {
     if [$failcount -gt 0]
     then
        echo – e "\n\n*** FAILED $failcount TESTS\n"
        exit 1 # In case we are part of something larger
     else
       exit 0 # In case we are part of something larger
     fi
   }
   #
   # Start the tests
   #
   expect_okay F12345678987654321OE # Should run thru
   expect_fail F5 # Fails, speed too high
   expect_fail 1 # Fails, empty
   expect_fail F10E1 # Fails, empty
   expect_fail F1238 # Fails, skips
   expect_okay FE # Never turn on
   expect_fail F1E # Emptying while running
   expect_okay F10E # Should be ok
   report # Report results
   При тестировании проверяется, не имеют ли место недопустимые переходы в скорости вращения ротора, если вы пытаетесь опорожнить работающий блендер, и т. д. Мы помещаем эту процедуру в сборочный файл, так что можно провести компиляцию и запустить регрессионный тест, просто введя команду:
   % make % make test
   Обратите внимание на то, что мы выходим из процедуры тестирования с 0 иди 1, так что можем использовать это и как часть более обширного теста.
   В требованиях ничего не говорилось о запуске данного компонента через сценарий или даже с использованием языка. Конечные пользователи этого не увидят. Но у нас есть мощный инструмент, который можно использовать для быстрого и исчерпывающего тестирования нашей программы.

Упражнение 42 из раздела "Ошибка в определении требований" Ответ:

   1. Эта инструкция похожа на реальное требование: имеются ограничения, налагаемые на приложение со стороны операционной среды.
   2. Это может быть корпоративным стандартом, но не требованием. Его лучше сформулировать так: "Фон диалогового окна должен настраиваться конечным пользователем. При поставке заказчику цвет будет серым". Еще лучше было бы сформулировать его более широко: "Все визуальные элементы приложения (цвета, шрифты и языки) должны настраиваться конечным пользователем".
   3. Эта формулировка не является требованием, это архитектура. Когда вы сталкиваетесь с подобным, вам придется копать очень глубоко, чтобы понять, что же думает пользователь.
   4. Основное требование, вероятно, выглядит примерно так: "Система предотвращает ввод пользователем недопустимых значений в поля и предупреждает пользователя, если ввод этих значений имеет место".
   5. Эта формулировка, по всей вероятности, является жестким требованием.
   Решение головоломки с четырьмя точками, приведенной в разделе "Разгадка невероятных головоломок".