97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф

задачу, но притом прекрасен, как песня? Да, как запавшая в память мелодия. Я думаю, что тот, кто сумел найти такое сложное решение, как предложенное тобой сегодня, может также написать что-нибудь красивое. Гм-м… Не начать ли мне выставлять оценки за красоту? Как ты считаешь, Джо?

Джо забрал свою работу и посмотрел на меня. Легкая улыбка пробежала по его лицу.

— Я все понял, профессор. Пойду улучшать мир для Фила. Спасибо.

Упущенные возможности применения полиморфизма

Кирк Пеппердин

Полиморфизм — одна из грандиозных идей, лежащих в фундаменте ООП. Это слово, заимствованное из греческого языка, означает множество (poly) форм (morph). В контексте программирования полиморфизм означает многообразие форм некоторого метода или класса объектов. Но полиморфизм — это не просто альтернативные реализации. Уместное применение полиморфизма создает миниатюрные локализованные контексты исполнения и позволяет обойтись без громоздких блоков if-then-else. Находясь в контексте, мы можем напрямую выполнять нужные действия, тогда как, находясь вне этого контекста, мы вынуждены сначала воссоздать его и лишь затем выполнять нужные действия. Аккуратное использование альтернативных реализаций позволяет выделить контекст, а значит, решить ту же задачу через меньший объем более удобочитаемого кода. Лучше всего продемонстрировать это на примере. Возьмем следующий код для (нереально) простой корзины покупок:

public class ShoppingCart {

   private ArrayList<Item> cart = new ArrayList<Item>();

   public void add(Item item) { cart.add(item); }

   public Item takeNext() { return cart.remove(0); }

   public boolean isEmpty() { return cart.isEmpty(); }

}

Допустим, некоторые товары в нашем интернет-магазине можно скачать из сети Интернет, а другие требуют доставки. Создадим другой класс, который поддерживает эти операции:

public class Shipping {

   public boolean ship(Item item, SurfaceAddress address) {… }

   public boolean ship(Item item, EMailAddress address) {… }

}

Когда клиент рассчитался, нужно доставить покупки:

while (!cart.isEmpty()) {

   shipping.ship(cart.takeNext(), ???);

}

Параметр ??? — это не какой-то очередной оператор Элвиса;[21] это неразрешенный вопрос о том, как нужно доставить товар — электронной или обычной почтой. Контекста для ответа на этот вопрос уже нет. Можно было сохранить метод доставки в виде boolean или enum, а затем использовать if-then-else, чтобы заполнить значение недостающего параметра. А другое решение — создать два класса, расширяющих Item. Назовем их DownloadableItem и SurfaceItem. Теперь напишем немного кода. Я сделаю из Item интерфейс, который поддерживает единственный метод ship (доставить). Чтобы доставить содержимое корзины, вызываем item. ship(shipper). Оба класса, DownloadableItem и SurfaceItem, реализуют ship:

public class DownloadableItem implements Item {

   public boolean ship(Shipping shipper, Customer customer) {

     shipper.ship(this, customer.getEmailAddress());

   }

}

public class SurfaceItem implements Item {

   public boolean ship(Shipping shipper, Customer customer)  {

     shipper.ship(this, customer.getSurfaceAddress());

   }

}

В этом примере мы делегировали ответственность за Shipping (доставку) каждому Item (товару). Поскольку каждый товар знает, как его следует доставлять, такая организация позволяет справиться с доставкой, не прибегая к if-then-else. Этот код также демонстрирует применение двух шаблонов проектирования, которые часто хорошо сочетаются между собой: Command и Double Dispatch. Эффективное применение этих шаблонов основано на правильном использовании полиморфизма. При выполнении этих условий число блоков if-then-else сокращается.

В некоторых ситуациях гораздо практичнее использовать не полиморфизм, а if-then-else, однако при написании кода в стиле полиморфизма он имеет меньший объем, более удобочитаем и менее хрупок. Количество упущенных возможностей несложно подсчитать — оно совпадает с числом операторов if-then-else в коде.

Невероятно, но факт: тестировщики — ваши друзья

Берк Хафнагель

Сами себя они могут называть контролем качества или обеспечением качества, но многие программисты зовут их просто напастью. Мой опыт показывает, что у программистов часто враждебные отношения с теми, кто тестирует их программы. «Они слишком придирчивы» или «Они хотят, чтобы все было идеально» — вот обычные жалобы. Знакомо, да?

Не знаю, по какой причине, но у меня всегда был другой взгляд на работу тестировщиков. Может быть потому, что «тестировщиком» на моей первой работе была секретарь фирмы. Весьма приятная дама Маргарет занималась делопроизводством и пыталась научить пару молодых программистов профессиональному поведению в присутствии клиентов. Она также обладала даром в считанные секунды обнаруживать любой дефект программы, даже самый малозаметный.

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

Вот почему я говорю, что тестировщики — ваши друзья. Может казаться, будто тестировщики портят вашу репутацию, сообщая о малозначительных проблемах. Но когда клиент в восторге от программы, потому что ему не портят жизнь все эти «досадные мелочи», которые группа контроля качества заставила вас исправить, вы на высоте. Мысль понятна?

Представьте себе такую ситуацию: вы тестируете программу, использующую «сногсшибательные алгоритмы искусственного интеллекта» для нахождения и исправления проблем с конкурентным доступом. Вы запускаете программу и обнаруживаете, что на заставке слово «интеллект» написано с ошибкой. Несколько дурное предзнаменование, но ведь это лишь опечатка, верно? Затем выясняется, что экран настройки предлагает флажки (checkboxes) вместо переключателей (radiobuttons), а некоторые сочетания клавиш не работают. Все это мелочи, но по мере их накопления вы начинаете задумываться, что за люди создавали программу. Если они неспособны справиться с простыми вещами, каковы шансы, что их искусственный интеллект действительно сумеет найти и исправить такие замысловатые вещи, как проблемы конкурентного доступа?

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