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

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

0

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

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

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

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

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

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

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

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

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

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

9

Сообщение от Psilon luigration, примерно одно и то же. Сейчас трудно сделать четкую грань между ними. Если взять исторически, то изначально был хаос макаронный код, с миллионами goto и прочими прелестями. Затем Дейстра опубликовал свою знаменитую заметку Go To Statement Considered Harmful, где сказал, в частности, что Так зародились идеи структурного программирования (смотри структурную теорему Бёма — Якопини, которая утерждвает, что goto не нужен). Все было хорошо, пока программы были маленькие. Но с увеличением объема кода росла сложность, многие куски кода просто копировались, хотя от goto уже помаленьку отошли. И тут пришла идея инкапсуляции - а давайте введем понятие модуля! Это когда есть функция, код внутри модуля может её использовать, а вне модуля - не может. Типичный пример - функции в разделе Implementation, которых нету в разделе Interface (в паскале), или функции , но которые не описаны в .h файле (в С). Чувствуете, на что это похоже? Да, правильно, но это будет чуть попозже... А такое программирование стали называть модульным. Время шло дальше, программы росли, и уже модульное программирование не справлялось со сложностью, от дублирование частично избавились, но модули теперь копировались целиком, что тоже не очень хорошо. И тут кому-то очень умному пришло в голову - а давайте не только функции скрывать, но и данные! А что, идея неплохая. Так зародились концепции ООП, которых четыре, а не три, как принято считать. Первая, и самая главная - это Абстракция. Остальные три - набившие оскомину - Наследование, Инкапсуляция и Полиморфизм. Второе - это прямое развитие идей модульного программирования. Полиморфизм был призван убрать дублирование кода, а Наследование - это способ его реализации, по факту (я пишу каждое слово с Большой Буквы, просто чтобы было заметнее, и придать вес словам По-идее, никак выделять эти слова не надо). Кстати, ООП придумали не В С++ и не Страуструп, как многие думают, а в малоизвестном на сегодня языке Smalltalk. А Страуструп просто вывел эти идеи на промышленные рельсы. Что, впрочем, не умаляет его заслуг. Время шло, программы росли.. Ничего не напоминает? В общем, ООП тоже начало задыхаться. В частности, очень много кода дублировало всевозможные обработки ошибок, логгирование и прочие вещи, которые в университетских программах не встречаются, а вот в промышленном коде занимают очень много места. И оборачивание каждого метода в километровые try catch с однотипным кодом начало убивать все преимущества ООП. И тут подумали - а почему бы нам не абстрагировать еще и поведение? Пусть обработка всех ошибок у нас будет в одном месте, а бизнес-логика - в другом. А еще что-нибудь - в третьем? Так и появилось новое направление - АОП. Есть некоторые его реализации на сегодняшний день, самая известная мне на сегодняшний день - реализация, основанная на новом API от Microsoft - проекте Rosylin. На самом деле интересный проект, предоставляющий API к компилятору и позволяющую делать интересные штуки, вот небольшой перечень того, что можно сделать Одним словом - первая промышленная реализация АОП (остальные имхо сейчас не очень соответствуют этому званию). АОП пока не выдохлось По большому счету оно пока только зарождается. Что будет дальше - посмотрим. Надеюсь, я достаточно подробно рассказал

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

0

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

0

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

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

2

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

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

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

1

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

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

2

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

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

0

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

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

0

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

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

0

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

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

0

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

0

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

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

0

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

0

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

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

0

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

0

1