Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Непейвода Н.Н. -> "Основания программирования " -> 58

Основания программирования - Непейвода Н.Н.

Непейвода Н.Н., Скопин И.Н. Основания программирования — Институт компьютерных исследований , 2002. — 919 c.
Скачать (прямая ссылка): osnovanprogramm2002.pdf
Предыдущая << 1 .. 52 53 54 55 56 57 < 58 > 59 60 61 62 63 64 .. 316 >> Следующая

Внимание!
Иногда накопленный опыт может быть перенесен на другие
,-
можности!
3.9.1. Программирование от переиспользования
Может показаться странным, что в обзоре стилей мы не выделили специально модульное программирование. самом деле, в программистском обиходе часто употребляется выражение «модульный стиль программирования». О днако если разобраться, то становится очевидным следующее.
Требование разрабатывать программы, в которых выделены автономныеи, соответственно, легкозаменяемыедругими, фрагменты, решающие логически замкнутые задачи, является обще,, присущим какой-либо специальной методике.
3.9. ТРИ ТЕХНОЛОГИЧЕСКИХ СТИЛЯ ПРОГРАММИРОВАНИЯ
157
менно это требование обычно трактуется как модульность программного изделия. Преимущества модульности, понимаемой в общем смысле, это: возможности замены модуля без изменения всего остального, и осуществимость повторного использования программных фрагментов. Вот последнее у е мо но рассматривать как особый стиль программирования, для которого модульность является основнм из средств.
Конкретные реализации модульности в системах программирования различны, но общий смысл понятия остается. Средства поддержки модульности характеризу т да е не стиль, а конкретнй язк, поддериваий этот стиль. поэтому правомерно говорить не о стиле, а о конкретном язке, в какой мере он поддеривает модульное построение программ в рамках своего стиля. К вопросу о языковой поддержке модуляризации мы еще возвратимся при обсуждении процедур как средства декомпозиции программ.
Стиль от переиспользования характеризуется тем, что при составлении программ стремятся максимально использовать то, что у е сделано — самим программистом, его коллегами или е вообе где-либо. идеале на смену программировани как кодировани алгоритмов долно прийти программирование как сборка из заранее заготовленных блоков — сборочное программирование. Этот термин введен одним из соавторов в статьях [58, 59, 60]. Г. С. Цейтин отделил это понятие от теоретических рассмотрений и представил его в работе [80] с чисто программистской стороны. Заметим, что практика математики у е давно отказалась от построения новых теорем (соответствующих в информатике программам) и новых понятий (соответ-ствуих абстрактным типам даннх) с самого начала. на весьма профессионально переиспользует ранее полученные результат . о в математике из-за концептуального единства систем понятий и строгих критериев обоснованности не возникает проблемы совместимости новх версий, которая зачастую губит попытки не просто переиспользования, но и просто использования старых программ.
онятно, что такое стремление далеко не всегда мо но реализовать на практике, что при использовании готовх строительных блоков возмо ны потери. Тем не менее, потенциальная выгода за счет переиспользования всегда обращает на себя внимание.
Рассмотрим две реальные ситуации, которые демонстрируют разработку, не ориентированну и ориентированну на переиспользование. В первой ситуации действует программист, работаий с очень развитой системой, в которой "есть все". Тем не менее, он пишет свою процедуру лексикографического упорядочивания строк, потому что «легче самому написать, чем найти,
158
3.
а потом, ведь еще и подгонять придется». Вывод: во-первых, здесь начисто отсутствует стремление к переиспользованию, а во-вторых, переиспользованию могут препятствовать затруднения поиска того, что требуется включить в составляему программу и проблемы совместимости версий.
Вторая ситуация — другая крайность. рограммисту на Java потребовалось построить синтаксический анализ. а вопрос о том, как он это делает, получен ответ: «Зачем это знать? У меня есть пакет JavaCC, который все делает, как надо!». Вместе с тем дальнейшие расспросы показали, что этот программист не представляет себе да е того, какого типа метод анализа поддеривает JavaCC, и, следовательно, ничего не мо ет сказать о том, как задание грамматики для данного пакета связано с эффективность анализа. Узнав возможные варианты, программист призадумался, но ничего менять не стал. Почему? Ответ простой: «Так ведь все уже работает!». Короче говоря, качесво использования гоовх компоненов сисем зависи о знания о них. Ситуация опять-таки та е самая, что в математике, особенно в прикладной. Квалифицированное использование теоретических результатов требует знания соответствующей теории, а порою и идей доказательств результатов (поскольку в реальной ситуации предположения теории никогда не выполняются точно). Глубина требуемого знания различна: иногда достаточно обего представления, как, например, при использовании математических функций, иногда ну н сведения о принципах реализации, но всегда мо но указать необходимый уровень знакомства с переиспользуемым.
Сравнение ситуаций показывает, что одних пожеланий и директивных указаний, что надо что-то переиспользовать, мало. у н знания о том, что мо но воспользоваться переносимми компонентами и как именно ими воспользоваться, получение которых часто требует суественных трудозатрат.
у но, чтобы само переиспользуемое программное обеспечение бло приспособлено для этого, в частности, чтобы оно в гораздо большей степени, чем сейчас, следовало накопленной в маемаике хороей прак ике, не игнорируя ее как чис у еори . Расифровка предыдуего предло ения позволит вдумчивому читател самому вывести все условия, необходимые для обеспечения переиспользования в конкретной обстановке.
Предыдущая << 1 .. 52 53 54 55 56 57 < 58 > 59 60 61 62 63 64 .. 316 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100