Форум программистов, компьютерный форум, киберфорум
Наши страницы

С++ для начинающих

Войти
Регистрация
Восстановить пароль
 
 
Рейтинг: Рейтинг темы: голосов - 16, средняя оценка - 4.81
luigration
2 / 2 / 0
Регистрация: 04.01.2013
Сообщений: 171
#1

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

23.06.2014, 14:26. Просмотров 2908. Ответов 16
Метки нет (Все метки)

Доброго всем времени суток. Объясните, пожалуйста, в чем различия между модульным, процедурным и структурным программированием? Читаю в википедии, как-то поверхностно понимаю, но какой-то особой разницы не нахожу.
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
23.06.2014, 14:26
Здравствуйте! Я подобрал для вас темы с ответами на вопрос В чем различия между модульным, процедурным и структурным программированием? (C++):

Различия между модульным и ООП программированием - C++
Привет, кто может в двух словах обьяснить различия между модульным и ООП программированием? Спасибо.

Различия компиляторов. В чем причина? - C++
есть небольшой код, который успешно компилируется в VS 2010 #include <iostream> template <class T> class complex { public: ...

В чем различия C# и C++ и что лучше учить? - C++
Здравствуйте! Скажите, какая существует разница между вышеупомянутыми языками? и какой из них выбрать для изучения?

Различия между Java и Си++ - C++
Я раньше программировал на си++,сейчас начал на java,нужно понять основные различия 1. Каковы отличия в структуре программы вычисления...

Различия между #define и const - C++
Собственно вопрос: в чем различия и что лучше использовать? Хотелось бы получить развернутый ответ со всеми "pros and cons".

scanf (какие различия между %f %g %e) - C++
Есть вопрос по функции scanf, а именно про спецификации формата. %f - читает число с плавающей точкой. %g - читает число с плавающей...

16
Psilon
Master of Orion
Эксперт .NET
5912 / 4809 / 634
Регистрация: 10.07.2011
Сообщений: 14,409
Записей в блоге: 5
Завершенные тесты: 4
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 к компилятору и позволяющую делать интересные штуки, вот небольшой перечень того, что можно сделать Одним словом - первая промышленная реализация АОП (остальные имхо сейчас не очень соответствуют этому званию).

АОП пока не выдохлось По большому счету оно пока только зарождается. Что будет дальше - посмотрим. Надеюсь, я достаточно подробно рассказал
8
luigration
2 / 2 / 0
Регистрация: 04.01.2013
Сообщений: 171
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
Эксперт .NET
5912 / 4809 / 634
Регистрация: 10.07.2011
Сообщений: 14,409
Записей в блоге: 5
Завершенные тесты: 4
23.06.2014, 19:42 #4
luigration, сам никогда не понимал Теоретически, процедурное программирование использует процедуры (внезапно), то есть методы, функции, subroutines, называйте как хотите. Не знаю, может в таком ракурсе структурное программирование подразумевает хреначенье всего кода в main... Ведь даже в ассемблере есть подпрограммы, то есть с этой точки зрения "процедурное" программирование было всегда. По крайней мере начиная с 50гг, если не раньше. Поэтому затрудняюсь ответить на этот вопрос
0
daslex
1286 / 530 / 109
Регистрация: 02.08.2011
Сообщений: 2,750
23.06.2014, 22:02 #5
В модульном - скрытность с глаз долой исходных кодов готовых модулей. из-за чего Сам код, в котором используются функции модулей не так сильно загроможден. Разбиение на файлы и использование этих файлов начинается уже с первой программы, с HelloWorld, когда пишем #include <О, Божественный компилятор, подари мне все скрытые способности0 этого файла>
___________________________
В структурном просто удобнее создавать и обрабатывать жалкое подобие баз данных и свои типы и объекты, соответствующие этим созданным типам. Также удобнее само обращение к данным. В маленьких программах этого не особо заметно, но в больших программах заметно. При этом внутри структурного программирования широко используется процедурное. Т.е. к каждому уникальному объекту можно присобачить функцию исключительно для него любимого. Это будет называться методом объекта., ну или задать значение переменой для него любимого.
_____________________________
Ну процедурное - это самое простое для понимания. В нужный момент времени нужно выполнить какой-то расчет или выполнить какую-то конкретную задачу. При этом момент времени может быть совершенно случайным и повторятся многократное количество раз. Как раз, чтобы не пихать все в main. , пытаясь угадать будущее, стали применять процедурное.
_____________________________

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

Остальное так.
1
Mr.X
Эксперт С++
3051 / 1696 / 265
Регистрация: 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
:)
Эксперт С++
4397 / 3233 / 297
Регистрация: 19.02.2013
Сообщений: 9,045
23.06.2014, 23:45 #8
Цитата Сообщение от Mr.X Посмотреть сообщение
С появлением структурных языков надобность в блок-схемах отпала, поэтому тоже довольно странно видеть как люди с ними возятся.
Вы о каких блок-схемах говорите? Это же классический подход для схематичного отображения алгоритма.
0
Mr.X
Эксперт С++
3051 / 1696 / 265
Регистрация: 03.05.2010
Сообщений: 3,867
23.06.2014, 23:51 #9
Цитата Сообщение от Tulosba Посмотреть сообщение
Вы о каких блок-схемах говорите? Это же классический подход для схематичного отображения алгоритма.
Ну так структурный язык сам способен описать схему алгоритма непосредственно в коде.
0
Tulosba
:)
Эксперт С++
4397 / 3233 / 297
Регистрация: 19.02.2013
Сообщений: 9,045
24.06.2014, 00:02 #10
Цитата Сообщение от Mr.X Посмотреть сообщение
Ну так структурный язык сам способен описать схему алгоритма непосредственно в коде.
Способов записи алгоритма может быть много. Любая программа - это по сути тоже способ записи алгоритма. И совершенно не важно на каком языке (поддерживающем какую парадигму) она написана. К тому же готовый алгоритм и процесс создания алгоритма - это не одно и то же. И вот во втором случае довольно удобно бывает блок-схему нарисовать. Да и пройтись по блокам, представленным на схеме куда нагляднее и быстрее способствует уяснению алгоритма нежели разбирать код. Как говорится - одна картинка заменяет тысячу слов.
0
Mr.X
Эксперт С++
3051 / 1696 / 265
Регистрация: 03.05.2010
Сообщений: 3,867
24.06.2014, 00:06 #11
Цитата Сообщение от Tulosba Посмотреть сообщение
Как говорится - одна картинка заменяет тысячу слов.
Ну, если вы визуал, то вполне возможно. Мне вот гораздо удобнее непосредственно на языке конструировать.
0
Psilon
Master of Orion
Эксперт .NET
5912 / 4809 / 634
Регистрация: 10.07.2011
Сообщений: 14,409
Записей в блоге: 5
Завершенные тесты: 4
24.06.2014, 00:18 #12
Mr.X, зависит от задачи. С тем же успехом можно сказать "UML для лохов, для настоящих про - простыня кода!" А UML по-факту и есть блок-схема, только не для структурного программирования, я для ООП.
0
Mr.X
Эксперт С++
3051 / 1696 / 265
Регистрация: 03.05.2010
Сообщений: 3,867
24.06.2014, 00:37 #13
Цитата Сообщение от Psilon Посмотреть сообщение
А UML по-факту и есть блок-схема, только не для структурного программирования, я для ООП.
Ну, здесь та же история, что и с обычными блок-схемами. Когда в языке не было структур – их рисовали на схемах. Сейчас в языке нет лаконичных и легко читаемых конструкций для отображения взаимодействия между объектами – приходится использовать UML.
0
Psilon
Master of Orion
Эксперт .NET
5912 / 4809 / 634
Регистрация: 10.07.2011
Сообщений: 14,409
Записей в блоге: 5
Завершенные тесты: 4
24.06.2014, 01:18 #14
Mr.X, эта теория не сходится с развитием методик "блок-схемного" программирования а-ля Windows Workflow(WWF) и иже с ними.
0
Mr.X
Эксперт С++
3051 / 1696 / 265
Регистрация: 03.05.2010
Сообщений: 3,867
24.06.2014, 01:29 #15
Цитата Сообщение от Psilon Посмотреть сообщение
Mr.X, эта теория не сходится с развитием методик "блок-схемного" программирования а-ля Windows Workflow(WWF) и иже с ними.
Ну, мне кажется, это у нас просто холивар между визуалами и невизуалами. UML тоже не все любят и используют.
0
24.06.2014, 01:29
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
24.06.2014, 01:29
Привет! Вот еще темы с ответами:

Различия между двумя циклами - C++
объясните различия между двумя следующими циклами while #include &lt;iostream&gt; using namespace std; int main () { const...

Различия в скоростях между curl и libcurl - C++
Качаю определенный файл через curl curl -O http://myhost.ru/myfile.txt Потом качаю через свою утилиту. #include &lt;stdio.h&gt; ...

Сравнить две строки на различия не учитывая кол-во пробелов и такие различия в буквах как о-и, н-т, в-д. - C++
Здравствуйте. Помогите пожалуйста дополнить программу. Суть программы - нужно сравнить две строки на различия не учитывая кол-во...

В чем различия константных объектов и константных ссылок на объекты в аргументах функций-членов? - C++
Как правильно необходимо указывать типы данных для входных параметров метода? Пример: void resetArguments(const int inputStrong,...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
15
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.