Бертран Мейер - Основы объектно-ориентированного программирования

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

Чтобы оценить эту ситуацию (для тех, кто разрабатывает ПО или руководит такой разработкой), полезно ответить на следующий вопрос:

Сколько раз за последние шесть месяцев вы, или те, кто работает на вас, разрабатывали некоторый вариант табличного поиска?

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

[x].Как уже отмечалось, вряд ли возможно создать полезную систему ПО, в которой не будут содержаться некоторые виды табличного поиска.

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

Почему же повторное использование еще не является общепринятым?

Наиболее серьезные препятствия к этому являются техническими; пути их преодоления будут обсуждаться в последующих разделах этой лекции (да и в остальных лекциях курса). Но, конечно, имеются также некоторые организационные, экономические и политические препятствия.

Психологическим препятствием повторного использования является известный синдром: "Придумано Не Нами" (Not Invented Here или "NIH"). Говорят, что разработчики ПО являются индивидуалистами, предпочитающими все выполнять сами, не полагаясь на чужую работу.

Но на практике это не подтверждается. Разработчики ПО склонны к бесполезной работе не более других специалистов. Если имеется хорошее, широко известное и легкодоступное повторно используемое решение, то оно будет использовано.

Рассмотрим типичный случай лексического и синтаксического анализа. Намного проще создать программу грамматического анализа для командного языка или простого языка программирования, используя программные генераторы грамматического разбора (parser generators), например комбинацию известных программ Lex-Yacc, а не создавая все с нуля. Вывод очевиден: там, где инструментальные средства имеются, квалифицированные разработчики ПО повсеместно их используют.

В некоторых случаях имеет смысл создание собственного нестандартного анализатора, поскольку у упомянутых инструментальных средств имеются свои ограничения. Но обычно разработчики предпочитают обращаться к одному из этих средств. Это может привести к новому синдрому, противоположномусиндрому NIH, который можно назвать синдромом "Привычки Препятствовать Нововведениям" (Habit Inhibiting Novelty или "HIN"). Повторно используемое решение, пусть даже полезное, но имеющее такие ограничения, которые сужают возможности разработчиков и подавляют внедрение новых идей, становится бесполезным. Попробуйте убедить кого-нибудь из разработчиков Unix'а использовать генератор грамматического разбора, отличающийся от Yacc, и вы можете на собственном опыте столкнуться с синдромом HIN.

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

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

Обозначим через N стоимость уникального решения, R - решения, основанного на повторно используемых компонентах. Значение R никогда не будет равно нулю: сюда войдут затраты на обучение, затраты на включение компонентов в систему, понадобиться создать интерфейс вызова. Так что даже если экономия на повторном использовании и другие выгоды

r=(N - R)/ N

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

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

Мне довелось слышать в высшей степени откровенное высказывание по этому вопросу после моей лекции о повторном использовании и ОО-технологии.