В чем различия между модульным, процедурным и структурным программированием?

@luigration · Регистрация: 04.01.2013

Author24 — интернет-сервис помощи студентам

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

Psilon · 23.06.2014, 16:55

luigration, примерно одно и то же. Сейчас трудно сделать четкую грань между ними.

Если взять исторически, то изначально был ~~хаос~~ макаронный код, с миллионами goto и прочими прелестями.

Затем Дейстра опубликовал свою знаменитую заметку Go To Statement Considered Harmful, где сказал, в частности, что

«За многие годы я утвердился во мнении о том, что квалификация программистов — функция, обратно зависящая от частоты появления операторов go to в их программах».

Так зародились идеи структурного программирования (смотри структурную теорему Бёма — Якопини, которая утерждвает, что goto не нужен).

Все было хорошо, пока программы были маленькие. Но с увеличением объема кода росла сложность, многие куски кода просто копировались, хотя от goto уже помаленьку отошли. И тут пришла идея инкапсуляции - а давайте введем понятие модуля! Это когда есть функция, код внутри модуля может её использовать, а вне модуля - не может. Типичный пример - функции в разделе Implementation, которых нету в разделе Interface (в паскале), или функции , но которые не описаны в .h файле (в С). Чувствуете, на что это похоже? Да, правильно, но это будет чуть попозже... А такое программирование стали называть модульным.

Время шло дальше, программы росли, и уже модульное программирование не справлялось со сложностью, от дублирование частично избавились, но модули теперь копировались целиком, что тоже не очень хорошо. И тут кому-то очень умному пришло в голову - а давайте не только функции скрывать, но и данные! А что, идея неплохая. Так зародились концепции ООП, которых четыре, а не три, как принято считать. Первая, и самая главная - это Абстракция. Остальные три - набившие оскомину - Наследование, Инкапсуляция и Полиморфизм. Второе - это прямое развитие идей модульного программирования. Полиморфизм был призван убрать дублирование кода, а Наследование - это способ его реализации, по факту (я пишу каждое слово с Большой Буквы, просто чтобы было заметнее, и придать вес словам

По-идее, никак выделять эти слова не надо).

Кстати, ООП придумали не В С++ и не Страуструп, как многие думают, а в малоизвестном на сегодня языке Smalltalk. А Страуструп просто вывел эти идеи на промышленные рельсы. Что, впрочем, не умаляет его заслуг.

Время шло, программы росли.. Ничего не напоминает?

В общем, ООП тоже начало задыхаться. В частности, очень много кода дублировало всевозможные обработки ошибок, логгирование и прочие вещи, которые в университетских программах не встречаются, а вот в промышленном коде занимают очень много места. И оборачивание каждого метода в километровые try catch с однотипным кодом начало убивать все преимущества ООП. И тут подумали - а почему бы нам не абстрагировать еще и поведение? Пусть обработка всех ошибок у нас будет в одном месте, а бизнес-логика - в другом. А еще что-нибудь - в третьем? Так и появилось новое направление - АОП. Есть некоторые его реализации на сегодняшний день, самая известная мне на сегодняшний день - реализация, основанная на новом API от Microsoft - проекте Rosylin. На самом деле интересный проект, предоставляющий API к компилятору и позволяющую делать интересные штуки, вот небольшой перечень того, что можно сделать

Одним словом - первая промышленная реализация АОП (остальные имхо сейчас не очень соответствуют этому званию).

АОП пока не выдохлось

По большому счету оно пока только зарождается. Что будет дальше - посмотрим. Надеюсь, я достаточно подробно рассказал

@luigration · 23.06.2014, 18:54 **[ТС]**

Сообщение от Psilon

luigration, примерно одно и то же. Сейчас трудно сделать четкую грань между ними.

Если взять исторически, то изначально был ~~хаос~~ макаронный код, с миллионами goto и прочими прелестями.

Затем Дейстра опубликовал свою знаменитую заметку Go To Statement Considered Harmful, где сказал, в частности, что
Так зародились идеи структурного программирования (смотри структурную теорему Бёма — Якопини, которая утерждвает, что goto не нужен).

Все было хорошо, пока программы были маленькие. Но с увеличением объема кода росла сложность, многие куски кода просто копировались, хотя от goto уже помаленьку отошли. И тут пришла идея инкапсуляции - а давайте введем понятие модуля! Это когда есть функция, код внутри модуля может её использовать, а вне модуля - не может. Типичный пример - функции в разделе Implementation, которых нету в разделе Interface (в паскале), или функции , но которые не описаны в .h файле (в С). Чувствуете, на что это похоже? Да, правильно, но это будет чуть попозже... А такое программирование стали называть модульным.

Время шло дальше, программы росли, и уже модульное программирование не справлялось со сложностью, от дублирование частично избавились, но модули теперь копировались целиком, что тоже не очень хорошо. И тут кому-то очень умному пришло в голову - а давайте не только функции скрывать, но и данные! А что, идея неплохая. Так зародились концепции ООП, которых четыре, а не три, как принято считать. Первая, и самая главная - это Абстракция. Остальные три - набившие оскомину - Наследование, Инкапсуляция и Полиморфизм. Второе - это прямое развитие идей модульного программирования. Полиморфизм был призван убрать дублирование кода, а Наследование - это способ его реализации, по факту (я пишу каждое слово с Большой Буквы, просто чтобы было заметнее, и придать вес словам

По-идее, никак выделять эти слова не надо).

Кстати, ООП придумали не В С++ и не Страуструп, как многие думают, а в малоизвестном на сегодня языке Smalltalk. А Страуструп просто вывел эти идеи на промышленные рельсы. Что, впрочем, не умаляет его заслуг.

Время шло, программы росли.. Ничего не напоминает?

В общем, ООП тоже начало задыхаться. В частности, очень много кода дублировало всевозможные обработки ошибок, логгирование и прочие вещи, которые в университетских программах не встречаются, а вот в промышленном коде занимают очень много места. И оборачивание каждого метода в километровые try catch с однотипным кодом начало убивать все преимущества ООП. И тут подумали - а почему бы нам не абстрагировать еще и поведение? Пусть обработка всех ошибок у нас будет в одном месте, а бизнес-логика - в другом. А еще что-нибудь - в третьем? Так и появилось новое направление - АОП. Есть некоторые его реализации на сегодняшний день, самая известная мне на сегодняшний день - реализация, основанная на новом API от Microsoft - проекте Rosylin. На самом деле интересный проект, предоставляющий API к компилятору и позволяющую делать интересные штуки, вот небольшой перечень того, что можно сделать

Одним словом - первая промышленная реализация АОП (остальные имхо сейчас не очень соответствуют этому званию).

АОП пока не выдохлось

По большому счету оно пока только зарождается. Что будет дальше - посмотрим. Надеюсь, я достаточно подробно рассказал

Про ООП мне всё понятно. А чем же тогда процедурное программирование отличается от структурного? Грубо говоря, особо ничем?

Psilon · 23.06.2014, 19:42

luigration, сам никогда не понимал

Теоретически, процедурное программирование использует процедуры (внезапно), то есть методы, функции, subroutines, называйте как хотите. Не знаю, может в таком ракурсе структурное программирование подразумевает хреначенье всего кода в main... Ведь даже в ассемблере есть подпрограммы, то есть с этой точки зрения "процедурное" программирование было всегда. По крайней мере начиная с 50гг, если не раньше. Поэтому затрудняюсь ответить на этот вопрос

@daslex · 23.06.2014, 22:02

В модульном - скрытность с глаз долой исходных кодов готовых модулей. из-за чего Сам код, в котором используются функции модулей не так сильно загроможден. Разбиение на файлы и использование этих файлов начинается уже с первой программы, с HelloWorld, когда пишем #include <О, Божественный компилятор, подари мне все скрытые способности0 этого файла>
___________________________
В структурном просто удобнее создавать и обрабатывать жалкое подобие баз данных и свои типы и объекты, соответствующие этим созданным типам. Также удобнее само обращение к данным. В маленьких программах этого не особо заметно, но в больших программах заметно. При этом внутри структурного программирования широко используется процедурное. Т.е. к каждому уникальному объекту можно присобачить функцию исключительно для него любимого. Это будет называться методом объекта., ну или задать значение переменой для него любимого.
_____________________________
Ну процедурное - это самое простое для понимания. В нужный момент времени нужно выполнить какой-то расчет или выполнить какую-то конкретную задачу. При этом момент времени может быть совершенно случайным и повторятся многократное количество раз. Как раз, чтобы не пихать все в main. , пытаясь угадать будущее, стали применять процедурное.
_____________________________

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

Psilon · 23.06.2014, 22:28

Сообщение от daslex

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

вообще не туда

Остальное так.

@Mr.X · 23.06.2014, 23:32

Сообщение от luigration

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

Ну, согласно Страуструпу, процедурное программирование – это использование в программе подпрограмм. В Паскале это процедуры и функции, в Си – только функции. Как видно из форума, у студентов-сишников с его освоением проблемы – фигачат весь код в main, что для человека, изучавшего Паскаль, выглядит довольно дико. В других языках, например в Паскале, подпрограмма может делать все, что делает программа, в том числе объявлять свои подпрограммы. В Си этого нет, и в функции уже невозможно объявить подфункцию, все функции глобальные.
Структурное программирование – это использование вместо goto готовых языковых структур – ветвлений и циклов. В Си это for, while, do while. if else, switch. Блок-схемы и были нужны, чтобы, когда этих структур в языке не было, рисовать их на бумажке, а потом реализовывать с помощью макаронного программирования, вписывая goto к номеру строки такой-то. С появлением структурных языков надобность в блок-схемах отпала, поэтому тоже довольно странно видеть как люди с ними возятся.
Модульное программирование – это разбиение программы на блоки функций (модули), каждый из которых выполняет свою задачу, и которые настолько независимы, что каждому модулю достаточно знать только интерфейсы других (т.е. имена функций модуля), а реализация этих функций его не интересует. В C++ это пространства имен на логическом уровне и файлы на физическом, где на логическом уровне интерфейс модуля (объявления функций) помещаются в пространстве имен модуля, а реализация модуля (реализации функций) – за пределами этого пространства имен. На физическом уровне интерфейсу модуля соответствует заголовочный файл модуля, а реализации – файл реализации модуля.

Tulosba · 23.06.2014, 23:45

Сообщение от Mr.X

С появлением структурных языков надобность в блок-схемах отпала, поэтому тоже довольно странно видеть как люди с ними возятся.

Вы о каких блок-схемах говорите? Это же классический подход для схематичного отображения алгоритма.

@Mr.X · 23.06.2014, 23:51

Сообщение от Tulosba

Вы о каких блок-схемах говорите? Это же классический подход для схематичного отображения алгоритма.

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

Tulosba · 24.06.2014, 00:02

Сообщение от Mr.X

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

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

@Mr.X · 24.06.2014, 00:06

Сообщение от Tulosba

Как говорится - одна картинка заменяет тысячу слов.

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

Psilon · 24.06.2014, 00:18

Mr.X, зависит от задачи. С тем же успехом можно сказать "UML для лохов, для настоящих про - простыня кода!" А UML по-факту и есть блок-схема, только не для структурного программирования, я для ООП.

@Mr.X · 24.06.2014, 00:37

Сообщение от Psilon

А UML по-факту и есть блок-схема, только не для структурного программирования, я для ООП.

Ну, здесь та же история, что и с обычными блок-схемами. Когда в языке не было структур – их рисовали на схемах. Сейчас в языке нет лаконичных и легко читаемых конструкций для отображения взаимодействия между объектами – приходится использовать UML.

Psilon · 24.06.2014, 01:18

Mr.X, эта теория не сходится с развитием методик "блок-схемного" программирования а-ля Windows Workflow(WWF) и иже с ними.

@Mr.X · 24.06.2014, 01:29

Сообщение от Psilon

Mr.X, эта теория не сходится с развитием методик "блок-схемного" программирования а-ля Windows Workflow(WWF) и иже с ними.

Ну, мне кажется, это у нас просто холивар между визуалами и невизуалами. UML тоже не все любят и используют.

Psilon · 24.06.2014, 02:10

Mr.X, я его не использую и не особо люблю. Тем не менее, признаю его право на жизнь, а не считаю недостающим звеном эволюции кода

@daslex · 24.06.2014, 14:56

PHP

На свете жил какой-то программист,
И на Ассемблере писал себе программы с GoTo                    //Императивное
Все говорили, что отличный он специалист,
Но весь тот код, спагетти-код рассеивал быстро смуту.
 
Как только код его жирел немного,
Никто уже его понять не мог,
У автора глаза краснели, сердился он жестоко,                //сложности императивного
Ведь даже сам он путался в своем от злого GoTo
 
Шло время, число краноглазиков росло.                        //сложности императивных порешали структурным
Тут появился некто Дейкстра Эдсгер,                                
Который победил такое злое GoTO, такое злое зло.
Вот Дейкстра клевый тип, талантище, ПРИМЕР!
 
И писали себе Программисты программы свои, 
И код их беспристрастно и сильно жирел,                                  //Но у структурного свои сложности
Цикл в цикл, Цикл в цикл, бесконечность зацикливалась уже в их головах.
Были и те, кому зацикленный беспредел уже надоел,
"Как бы все упростить",- мысли пробегали в ихних умах.
 
 
И снова проблемы волной большой накатились
Уж очень сильно исходники загроможденными стали
Так как-то программисты и не заметили, но в годы 40-е они откатились,    //отражение архитектуры традиционных ЭВМ, которая была предложена фон Нейманом в 1940-х годах.
К архитектуре ЭВМ фон Неймана, которого как старье поди изучали.         //это процедурное программирование
 
 
..
 
Я к чему - это. Если исторически, то, наверное, можно сказать, что процедурное программирование есть своего рода надмножество структурного. Цель - упрощение структурного. И сам по себе мир программирования идет накатами волн.
Я, может, немного преувеличил (но это так, для рифмы просто).

@Mr.X 3224 / 1751 / 436 Регистрация: 03.05.2010 Сообщений: 3,867
	24.06.2014, 00:06	11
	Сообщение от Tulosba Как говорится - одна картинка заменяет тысячу слов. Ну, если вы визуал, то вполне возможно. Мне вот гораздо удобнее непосредственно на языке конструировать. 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	24.06.2014, 00:18	12
	Mr.X, зависит от задачи. С тем же успехом можно сказать "UML для лохов, для настоящих про - простыня кода!" А UML по-факту и есть блок-схема, только не для структурного программирования, я для ООП. 0

@Mr.X 3224 / 1751 / 436 Регистрация: 03.05.2010 Сообщений: 3,867
	24.06.2014, 01:29	15
	Сообщение от Psilon Mr.X, эта теория не сходится с развитием методик "блок-схемного" программирования а-ля Windows Workflow(WWF) и иже с ними. Ну, мне кажется, это у нас просто холивар между визуалами и невизуалами. UML тоже не все любят и используют. 0

@luigration 12 / 9 / 5 Регистрация: 04.01.2013 Сообщений: 205
		1
	В чем различия между модульным, процедурным и структурным программированием? 23.06.2014, 14:26. Показов 9490. Ответов 16 Метки нет (Все метки) Доброго всем времени суток. Объясните, пожалуйста, в чем различия между модульным, процедурным и структурным программированием? Читаю в википедии, как-то поверхностно понимаю, но какой-то особой разницы не нахожу. 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	23.06.2014, 16:55	2
	luigration, примерно одно и то же. Сейчас трудно сделать четкую грань между ними. Если взять исторически, то изначально был ~~хаос~~ макаронный код, с миллионами goto и прочими прелестями. Затем Дейстра опубликовал свою знаменитую заметку Go To Statement Considered Harmful, где сказал, в частности, что «За многие годы я утвердился во мнении о том, что квалификация программистов — функция, обратно зависящая от частоты появления операторов go to в их программах». Так зародились идеи структурного программирования (смотри структурную теорему Бёма — Якопини, которая утерждвает, что goto *не нужен). Все было хорошо, пока программы были маленькие. Но с увеличением объема кода росла сложность, многие куски кода просто копировались, хотя от goto уже помаленьку отошли. И тут пришла идея инкапсуляции - а давайте введем понятие модуля! Это когда есть функция, код внутри модуля может её использовать, а вне модуля - не может. Типичный пример - функции в разделе Implementation, которых нету в разделе Interface (в паскале), или функции , но которые не описаны в .h файле (в С). Чувствуете, на что это похоже? Да, правильно, но это будет чуть попозже... А такое программирование стали называть модульным. Время шло дальше, программы росли, и уже модульное программирование не справлялось со сложностью, от дублирование частично избавились, но модули теперь копировались целиком, что тоже не очень хорошо. И тут кому-то очень умному пришло в голову - а давайте не только функции скрывать, но и данные! А что, идея неплохая. Так зародились концепции ООП, которых четыре, а не три, как принято считать. Первая, и самая главная - это Абстракция. Остальные три - набившие оскомину - Наследование, Инкапсуляция и Полиморфизм. Второе - это прямое развитие идей модульного программирования. Полиморфизм был призван убрать дублирование кода, а Наследование - это способ его реализации, по факту (я пишу каждое слово с Большой Буквы, просто чтобы было заметнее, и придать вес словам По-идее, никак выделять эти слова не надо). Кстати, ООП придумали не В С++ и не Страуструп, как многие думают, а в малоизвестном на сегодня языке Smalltalk. А Страуструп просто вывел эти идеи на промышленные рельсы. Что, впрочем, не умаляет его заслуг. Время шло, программы росли.. Ничего не напоминает? В общем, ООП тоже начало задыхаться. В частности, очень много кода дублировало всевозможные обработки ошибок, логгирование и прочие вещи, которые в университетских программах не встречаются, а вот в промышленном коде занимают очень много места. И оборачивание каждого метода в километровые try catch* с однотипным кодом начало убивать все преимущества ООП. И тут подумали - а почему бы нам не абстрагировать еще и поведение? Пусть обработка всех ошибок у нас будет в одном месте, а бизнес-логика - в другом. А еще что-нибудь - в третьем? Так и появилось новое направление - АОП. Есть некоторые его реализации на сегодняшний день, самая известная мне на сегодняшний день - реализация, основанная на новом API от Microsoft - проекте Rosylin. На самом деле интересный проект, предоставляющий API к компилятору и позволяющую делать интересные штуки, вот небольшой перечень того, что можно сделать Одним словом - первая промышленная реализация АОП (остальные имхо сейчас не очень соответствуют этому званию). АОП пока не выдохлось По большому счету оно пока только зарождается. Что будет дальше - посмотрим. Надеюсь, я достаточно подробно рассказал 9

@luigration 12 / 9 / 5 Регистрация: 04.01.2013 Сообщений: 205
	23.06.2014, 18:54 [ТС]	3
	Сообщение от Psilon luigration, примерно одно и то же. Сейчас трудно сделать четкую грань между ними. Если взять исторически, то изначально был ~~хаос~~ макаронный код, с миллионами goto и прочими прелестями. Затем Дейстра опубликовал свою знаменитую заметку Go To Statement Considered Harmful, где сказал, в частности, что Так зародились идеи структурного программирования (смотри структурную теорему Бёма — Якопини, которая утерждвает, что goto *не нужен). Все было хорошо, пока программы были маленькие. Но с увеличением объема кода росла сложность, многие куски кода просто копировались, хотя от goto уже помаленьку отошли. И тут пришла идея инкапсуляции - а давайте введем понятие модуля! Это когда есть функция, код внутри модуля может её использовать, а вне модуля - не может. Типичный пример - функции в разделе Implementation, которых нету в разделе Interface (в паскале), или функции , но которые не описаны в .h файле (в С). Чувствуете, на что это похоже? Да, правильно, но это будет чуть попозже... А такое программирование стали называть модульным. Время шло дальше, программы росли, и уже модульное программирование не справлялось со сложностью, от дублирование частично избавились, но модули теперь копировались целиком, что тоже не очень хорошо. И тут кому-то очень умному пришло в голову - а давайте не только функции скрывать, но и данные! А что, идея неплохая. Так зародились концепции ООП, которых четыре, а не три, как принято считать. Первая, и самая главная - это Абстракция. Остальные три - набившие оскомину - Наследование, Инкапсуляция и Полиморфизм. Второе - это прямое развитие идей модульного программирования. Полиморфизм был призван убрать дублирование кода, а Наследование - это способ его реализации, по факту (я пишу каждое слово с Большой Буквы, просто чтобы было заметнее, и придать вес словам По-идее, никак выделять эти слова не надо). Кстати, ООП придумали не В С++ и не Страуструп, как многие думают, а в малоизвестном на сегодня языке Smalltalk. А Страуструп просто вывел эти идеи на промышленные рельсы. Что, впрочем, не умаляет его заслуг. Время шло, программы росли.. Ничего не напоминает? В общем, ООП тоже начало задыхаться. В частности, очень много кода дублировало всевозможные обработки ошибок, логгирование и прочие вещи, которые в университетских программах не встречаются, а вот в промышленном коде занимают очень много места. И оборачивание каждого метода в километровые try catch* с однотипным кодом начало убивать все преимущества ООП. И тут подумали - а почему бы нам не абстрагировать еще и поведение? Пусть обработка всех ошибок у нас будет в одном месте, а бизнес-логика - в другом. А еще что-нибудь - в третьем? Так и появилось новое направление - АОП. Есть некоторые его реализации на сегодняшний день, самая известная мне на сегодняшний день - реализация, основанная на новом API от Microsoft - проекте Rosylin. На самом деле интересный проект, предоставляющий API к компилятору и позволяющую делать интересные штуки, вот небольшой перечень того, что можно сделать Одним словом - первая промышленная реализация АОП (остальные имхо сейчас не очень соответствуют этому званию). АОП пока не выдохлось По большому счету оно пока только зарождается. Что будет дальше - посмотрим. Надеюсь, я достаточно подробно рассказал Про ООП мне всё понятно. А чем же тогда процедурное программирование отличается от структурного? Грубо говоря, особо ничем? 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	23.06.2014, 19:42	4
	luigration, сам никогда не понимал Теоретически, процедурное программирование использует процедуры (внезапно), то есть методы, функции, subroutines, называйте как хотите. Не знаю, может в таком ракурсе структурное программирование подразумевает хреначенье всего кода в main... Ведь даже в ассемблере есть подпрограммы, то есть с этой точки зрения "процедурное" программирование было всегда. По крайней мере начиная с 50гг, если не раньше. Поэтому затрудняюсь ответить на этот вопрос 0

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,882
	23.06.2014, 22:02	5
	В модульном - скрытность с глаз долой исходных кодов готовых модулей. из-за чего Сам код, в котором используются функции модулей не так сильно загроможден. Разбиение на файлы и использование этих файлов начинается уже с первой программы, с HelloWorld, когда пишем #include <О, Божественный компилятор, подари мне все скрытые способности0 этого файла> ___________________________ В структурном просто удобнее создавать и обрабатывать жалкое подобие баз данных и свои типы и объекты, соответствующие этим созданным типам. Также удобнее само обращение к данным. В маленьких программах этого не особо заметно, но в больших программах заметно. При этом внутри структурного программирования широко используется процедурное. Т.е. к каждому уникальному объекту можно присобачить функцию исключительно для него любимого. Это будет называться методом объекта., ну или задать значение переменой для него любимого. _____________________________ Ну процедурное - это самое простое для понимания. В нужный момент времени нужно выполнить какой-то расчет или выполнить какую-то конкретную задачу. При этом момент времени может быть совершенно случайным и повторятся многократное количество раз. Как раз, чтобы не пихать все в main. , пытаясь угадать будущее, стали применять процедурное. _____________________________ При этом все три не взаимоисключающие, все эти подходы программирования можно и иногда нужно сочетать между собой. Всфя разница только в том, что в какой-то конкретной задаче чуть более удобный один из способов программирования.,вот и все. 2

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	23.06.2014, 22:28	6
	Сообщение от daslex В структурном просто удобнее создавать и обрабатывать жалкое подобие баз данных и свои типы и объекты, соответствующие этим созданным типам. Также удобнее само обращение к данным. В маленьких программах этого не особо заметно, но в больших программах заметно. При этом внутри структурного программирования широко используется процедурное. Т.е. к каждому уникальному объекту можно присобачить функцию исключительно для него любимого. Это будет называться методом объекта., ну или задать значение переменой для него любимого. вообще не туда Остальное так. 1

@Mr.X 3224 / 1751 / 436 Регистрация: 03.05.2010 Сообщений: 3,867
	23.06.2014, 23:32	7
	Сообщение от luigration Объясните, пожалуйста, в чем различия между модульным, процедурным и структурным программированием? Ну, согласно Страуструпу, процедурное программирование – это использование в программе подпрограмм. В Паскале это процедуры и функции, в Си – только функции. Как видно из форума, у студентов-сишников с его освоением проблемы – фигачат весь код в main, что для человека, изучавшего Паскаль, выглядит довольно дико. В других языках, например в Паскале, подпрограмма может делать все, что делает программа, в том числе объявлять свои подпрограммы. В Си этого нет, и в функции уже невозможно объявить подфункцию, все функции глобальные. Структурное программирование – это использование вместо goto готовых языковых структур – ветвлений и циклов. В Си это for, while, do while. if else, switch. Блок-схемы и были нужны, чтобы, когда этих структур в языке не было, рисовать их на бумажке, а потом реализовывать с помощью макаронного программирования, вписывая goto к номеру строки такой-то. С появлением структурных языков надобность в блок-схемах отпала, поэтому тоже довольно странно видеть как люди с ними возятся. Модульное программирование – это разбиение программы на блоки функций (модули), каждый из которых выполняет свою задачу, и которые настолько независимы, что каждому модулю достаточно знать только интерфейсы других (т.е. имена функций модуля), а реализация этих функций его не интересует. В C++ это пространства имен на логическом уровне и файлы на физическом, где на логическом уровне интерфейс модуля (объявления функций) помещаются в пространстве имен модуля, а реализация модуля (реализации функций) – за пределами этого пространства имен. На физическом уровне интерфейсу модуля соответствует заголовочный файл модуля, а реализации – файл реализации модуля. 2

Tulosba :) 4773 / 3267 / 497 Регистрация: 19.02.2013 Сообщений: 9,046
	23.06.2014, 23:45	8
	Сообщение от Mr.X С появлением структурных языков надобность в блок-схемах отпала, поэтому тоже довольно странно видеть как люди с ними возятся. Вы о каких блок-схемах говорите? Это же классический подход для схематичного отображения алгоритма. 0

@Mr.X 3224 / 1751 / 436 Регистрация: 03.05.2010 Сообщений: 3,867
	23.06.2014, 23:51	9
	Сообщение от Tulosba Вы о каких блок-схемах говорите? Это же классический подход для схематичного отображения алгоритма. Ну так структурный язык сам способен описать схему алгоритма непосредственно в коде. 0

Tulosba :) 4773 / 3267 / 497 Регистрация: 19.02.2013 Сообщений: 9,046
	24.06.2014, 00:02	10
	Сообщение от Mr.X Ну так структурный язык сам способен описать схему алгоритма непосредственно в коде. Способов записи алгоритма может быть много. Любая программа - это по сути тоже способ записи алгоритма. И совершенно не важно на каком языке (поддерживающем какую парадигму) она написана. К тому же готовый алгоритм и процесс создания алгоритма - это не одно и то же. И вот во втором случае довольно удобно бывает блок-схему нарисовать. Да и пройтись по блокам, представленным на схеме куда нагляднее и быстрее способствует уяснению алгоритма нежели разбирать код. Как говорится - одна картинка заменяет тысячу слов. 0

	24.06.2014, 14:56

@Mr.X 3224 / 1751 / 436 Регистрация: 03.05.2010 Сообщений: 3,867
	24.06.2014, 00:37	13
	Сообщение от Psilon А UML по-факту и есть блок-схема, только не для структурного программирования, я для ООП. Ну, здесь та же история, что и с обычными блок-схемами. Когда в языке не было структур – их рисовали на схемах. Сейчас в языке нет лаконичных и легко читаемых конструкций для отображения взаимодействия между объектами – приходится использовать UML. 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	24.06.2014, 01:18	14
	Mr.X, эта теория не сходится с развитием методик "блок-схемного" программирования а-ля Windows Workflow(WWF) и иже с ними. 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	24.06.2014, 02:10	16
	Mr.X, я его не использую и не особо люблю. Тем не менее, признаю его право на жизнь, а не считаю недостающим звеном эволюции кода 0