ID: 36222

Название работы: Парадигмы программирования. Правила структурного программирования

Категория: Доклад

Предметная область: Информатика, кибернетика и программирование

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

Язык: Русский

Дата добавления: 2015-01-18

Размер файла: 37.5 KB

Работу скачали: 1 чел.

Парадигмы программирования

Программирование как таковое существует с середины XX века. По преобладанию определённой парадигмы можно различить три периода:

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

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

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

Но не было и объективной необходимости ставить читабельность одним из основных качеств программы:

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

1.  Со временем умножились потребности общества в очень разноплановом ПО, создание которого стало возможным благодаря качественно – значимому росту потенциала электронной техники. В тысячи раз возросли быстродействие, и память ЭВМ. Это позволило создавать уже не компактные программы, а огромные программные комплексы, так называемые пакеты программ.  Совместная работа многих программистов в рамках одного проекта стала насущной потребностью. А она бесконечно осложнялась беспорядочностью программ и их плохой читабельностью.

В конце 60-х годов знаменитый программист Эдсгер Дейкстра, обозначив проблему, первым ввёл термин структурное программирование. Он обозначил им необходимость следовать при написании программ определенным правилам, придерживаться строгой иерархии при структурировании программы и признал «оператор GOTO вредным». Это вызвало ожесточённую полемику в рядах программистов. Итогом её была  победа структурного мышления.

Структурное программирование – это дисциплина,  которую программист навязывает сам себе, имея целью создание качественного ПО.

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

Правила структурного программирования

1.  При построении структуры пакета программ, придерживаться иерархической структуры, избегая беспорядочного вызова мелких подпрограмм.
2.  Каждая подпрограмма должны выполнять законченную логическую функцию.
3.  Желательно, чтобы размер подпрограммы не превышал 100 операторов (оптимально -25 операторов, которые можно одновременно увидеть на экране монитора).
4.  Использовать только обобщённые управляющие конструкции (см. след. раздел), применять оператор GOTO только в специальных, «разрешённых» случаях (например при переходе на конец программы).
5.  Заботиться о прозрачности программ, о возможности их тестирования ещё на этапе разработки структуры пакета, приступать к написанию тестов ещё до написания программ.
6.  Повышать «читабельность» программы, для чего следует:

•  Избегать вложенности циклов и операторов IF более 3-х уровней
•  Избегать так называемых «программистких трюков» всегда отдавая предпочтения наиболее понятному варианту при написании кода.
•  Использовать «говорящие» идентификаторы, родственные идентификаторы должны начинаться с одинакового префикса.
•  Комментировать программу

1.  Следующий кризис программирования произошёл двадцать лет спустя.  К этому времени неизмеримо возросли возможности электронной техники. Вычислительные задачи перестали быть основным её предназначением. С появлением персональных компьютеров (ПК) наиболее распространёнными стали мультимедийные задачи. Потребность в написании программ стала столь велика, что невозможно стало её удовлетворение «ручным» способом. Насущной стала проблема автоматизации процесса программирования.

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

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

В 1989 году началась так называемая война методологий. До того времени господствовала структурная парадигма. С появлением возможностей объектно-ориентированного программирования  появилась парадигма ООП. Надо сказать, что она не отрицает структурную парадигму и скорее строится на ее базе.

Основу  ООП составляют :

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