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

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

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

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

Нетехнические препятствия

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

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

Синдром NIH

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

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

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

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

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

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

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

r=(N - R)/ N

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

Этим объясняется, почему ошибочной целью является политика фирмы, направленная на работу с потенциальными повторными пользователями (потребителями, как их называют разработчики). Вместо этого следует ужесточить требования к производителям внешних компонентов, требуя гарантий качества и пригодности предлагаемой ими продукции. Разработчики прикладных систем будут использовать ваши компоненты не в связи с вашими рекомендациями, а потому, что вы хорошо потрудились над тем, чтобы повторно используемые компоненты было выгодно применять в прикладных программах.

Фирмы по разработке ПО и их стратегии

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

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

Высокопоставленный администратор из крупной фирмы по поставкам ПО сказал мне, что хотя он сознает высокую ценность этих идей, но никогда не будет внедрять их в своей фирме, поскольку не хочет резать курицу, несущую золотые яйца. Более 90% доходов его фирма получает от "сдачи напрокат" личного состава, предоставляя заказчикам услуги своих аналитиков и программистов, и руководство фирмы стремится довести эту цифру до 100%. При таком отношении к разработке ПО навряд ли будет встречена с энтузиазмом перспектива появления общедоступных библиотек повторно используемых компонентов.

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

Технологическая составляющая (engineering part) в разработке ПО не идентична такой же составляющей в индустрии массового производства; человеческий фактор будет, вероятно, по-прежнему играть ключевую роль в процессе конструирования ПО.

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

[x]. Во многих случаях разработчики, применяющие повторно используемые компоненты, могут по-прежнему успешно пользоваться помощью специалистов, которые посоветуют, как наилучшим образом применять эти компоненты. Тем самым сохраняется существенная роль фирм по поставкам ПО и их консультантов.

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

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