В данном сообщении речь пойдет об одном из методов разработки - структурном программировании. На мой взгляд именно этот подход преобладает при построении простых программ, целью которых является получение и обработка данных.
-------------- Структу́рное программи́рование — методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. --------------
Для начала неплохо. И еще немного теории:
-------------- ...на практике используют некоторые методы, облегчающие построение и реализацию алгоритмов.
Одним из наиболее распространенных является метод структурного программирования, или конструирование алгоритмов методом последовательной детализации. При пошаговой детализации алгоритмы записываются в виде множества вспомогательных алгоритмов, решающих вспомогательные подзадачи, а каждая из них требует получения определенных промежуточных результатов.
Разработав основной алгоритм, можно приступить к разработке алгоритмов «второго уровня», которые, в свою очередь, могут требовать дальнейшей детализации. Процесс детализации продолжается до тех пор, пока не будут написаны все нужные вспомогательные алгоритмы. Таким образом, основной алгоритм представляет собой план действий, которые необходимо выполнить для достижения поставленной цели, а суть каждого действия расшифровывается в соответствующем вспомогательном алгоритме.
Каждый вспомогательный алгоритм описывает способ решения некоторой вспомогательной задачи или даже общий способ решения некоторого класса вспомогательных подзадач. Для реализации вспомогательных алгоритмов служат подпрограммы, или процедуры. (источник) --------------
Применяем на практике
В большинстве своем программы обработки данных выглядят следующим образом: [vba]
Код
Sub Main() ' 1. получение исходных данных
' 2. магия (манипуляции с данными)
' 3. вывод результата End Sub
[/vba] Как видите основная часть программы уже написана : )
Function GetData(Params) ' процесс получения данных End Function
Sub DoSomeActions(Data) ' произвести какие-то действия End Sub
Sub WriteResult(Destination, Data) ' выводим результат обработки данных End Sub
[/vba]
Разумеется, внутри GetData, DoSomeActions и WriteResult можно и даже нужно вызывать другие необходимые функции/процедуры, если того требует задача.
В чем соль: - благодаря вспомогательным функциям/процедурам, логика "главной" процедура Sub Main не пострадала (не захламлена логикой реализации вспомогательных алгоритмов) - данный подход позволяет проектировать (строить) программу буквально на лету - проще тестировать (в виду разбиения логики). Написали, отладили одну часть, переходим к разработке другой - и т.д.
Всем привет
В данном сообщении речь пойдет об одном из методов разработки - структурном программировании. На мой взгляд именно этот подход преобладает при построении простых программ, целью которых является получение и обработка данных.
-------------- Структу́рное программи́рование — методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. --------------
Для начала неплохо. И еще немного теории:
-------------- ...на практике используют некоторые методы, облегчающие построение и реализацию алгоритмов.
Одним из наиболее распространенных является метод структурного программирования, или конструирование алгоритмов методом последовательной детализации. При пошаговой детализации алгоритмы записываются в виде множества вспомогательных алгоритмов, решающих вспомогательные подзадачи, а каждая из них требует получения определенных промежуточных результатов.
Разработав основной алгоритм, можно приступить к разработке алгоритмов «второго уровня», которые, в свою очередь, могут требовать дальнейшей детализации. Процесс детализации продолжается до тех пор, пока не будут написаны все нужные вспомогательные алгоритмы. Таким образом, основной алгоритм представляет собой план действий, которые необходимо выполнить для достижения поставленной цели, а суть каждого действия расшифровывается в соответствующем вспомогательном алгоритме.
Каждый вспомогательный алгоритм описывает способ решения некоторой вспомогательной задачи или даже общий способ решения некоторого класса вспомогательных подзадач. Для реализации вспомогательных алгоритмов служат подпрограммы, или процедуры. (источник) --------------
Применяем на практике
В большинстве своем программы обработки данных выглядят следующим образом: [vba]
Код
Sub Main() ' 1. получение исходных данных
' 2. магия (манипуляции с данными)
' 3. вывод результата End Sub
[/vba] Как видите основная часть программы уже написана : )
Function GetData(Params) ' процесс получения данных End Function
Sub DoSomeActions(Data) ' произвести какие-то действия End Sub
Sub WriteResult(Destination, Data) ' выводим результат обработки данных End Sub
[/vba]
Разумеется, внутри GetData, DoSomeActions и WriteResult можно и даже нужно вызывать другие необходимые функции/процедуры, если того требует задача.
В чем соль: - благодаря вспомогательным функциям/процедурам, логика "главной" процедура Sub Main не пострадала (не захламлена логикой реализации вспомогательных алгоритмов) - данный подход позволяет проектировать (строить) программу буквально на лету - проще тестировать (в виду разбиения логики). Написали, отладили одну часть, переходим к разработке другой - и т.д.nerv
Чебурашка стал символом олимпийских игр. А чего достиг ты? Тишина - самый громкий звук
"Проектирование сверху вниз" - один из стандартов реализации. Только вот к "структурному программированию" он отношения нынче практически не имеет (а уж если подходить с точки зрения любого функционального языка, то... ), или, наоборот, имеет самое непосредственное (и в результате этого мы наблюдаем либо "действие залетевшего дятла", либо игнор исключений с возвратом чуть не в нулевое кольцо... Не смешивай, пожалуйста, парадигму структурного программирования с ООП (поскольку всё же Офис) - простые пользователи и даже отвечающие могут просто не понять... В качестве примера: возьмём Excel и сделаем реализацию только на событиях - хотя "структура" и будет присутствовать в виде объектной модели приложения, но нам не надо задумываться об уровнях абстрагирования... хотя парадигма "проектирования" соблюдена полностью - просто все "процедуры" уже предусмотрены моделью
— Ты функциональщик! - прокричал Сергей на весь оупен-спейс-рум номер 14. Комната притихла в ожидании развязки. — Я видел, как ты вчера вечером каррировал и декаррировал прямо за рабочим компьютером! Неодобрительный ропот и возгласы удивления прокатились по комнате. Кто-то громким шепотом сказал “какой ужас, а я с ним за руку здоровался”. — Знаешь что, Сергей, — сказал Денис, вставая из-за рабочего стола, — любой нормальный мужчина, если у него всё в порядке, может позволить себе позаниматься функциональным программированием. Это естественно. Каждый хотя бы раз, да пробовал. Зачем только об этом кричать на всю комнату? Я же не кричу, что ты объектно-ориентированный! Девушки захихикали, кто-то снова громко пробормотал “ну надо же, а по нему и не скажешь”. Присутствовавший при этом Игорь Матвеевич сильнее вжался в кресло. Только бы никто не узнал про его процедурные наклонности!
С другой стороны - да, цепочка "получить данные - обработать полученные данные - вывести результат обработки" остаётся до сих пор самой распространённой операцией. Но, ПМСМ, упор нужно делать именно на правильное распределение действий по этим этапам - а уж внутри "этапа" применять именно "структурное программирование" в пределах, предоставленных "встроенным языком программирования" или "функционалом приложения".
"Проектирование сверху вниз" - один из стандартов реализации. Только вот к "структурному программированию" он отношения нынче практически не имеет (а уж если подходить с точки зрения любого функционального языка, то... ), или, наоборот, имеет самое непосредственное (и в результате этого мы наблюдаем либо "действие залетевшего дятла", либо игнор исключений с возвратом чуть не в нулевое кольцо... Не смешивай, пожалуйста, парадигму структурного программирования с ООП (поскольку всё же Офис) - простые пользователи и даже отвечающие могут просто не понять... В качестве примера: возьмём Excel и сделаем реализацию только на событиях - хотя "структура" и будет присутствовать в виде объектной модели приложения, но нам не надо задумываться об уровнях абстрагирования... хотя парадигма "проектирования" соблюдена полностью - просто все "процедуры" уже предусмотрены моделью
— Ты функциональщик! - прокричал Сергей на весь оупен-спейс-рум номер 14. Комната притихла в ожидании развязки. — Я видел, как ты вчера вечером каррировал и декаррировал прямо за рабочим компьютером! Неодобрительный ропот и возгласы удивления прокатились по комнате. Кто-то громким шепотом сказал “какой ужас, а я с ним за руку здоровался”. — Знаешь что, Сергей, — сказал Денис, вставая из-за рабочего стола, — любой нормальный мужчина, если у него всё в порядке, может позволить себе позаниматься функциональным программированием. Это естественно. Каждый хотя бы раз, да пробовал. Зачем только об этом кричать на всю комнату? Я же не кричу, что ты объектно-ориентированный! Девушки захихикали, кто-то снова громко пробормотал “ну надо же, а по нему и не скажешь”. Присутствовавший при этом Игорь Матвеевич сильнее вжался в кресло. Только бы никто не узнал про его процедурные наклонности!
С другой стороны - да, цепочка "получить данные - обработать полученные данные - вывести результат обработки" остаётся до сих пор самой распространённой операцией. Но, ПМСМ, упор нужно делать именно на правильное распределение действий по этим этапам - а уж внутри "этапа" применять именно "структурное программирование" в пределах, предоставленных "встроенным языком программирования" или "функционалом приложения".AndreTM
Skype: andre.tm.007 Donate: Qiwi: 9517375010
Сообщение отредактировал AndreTM - Вторник, 18.06.2013, 04:13
"Проектирование сверху вниз" - один из стандартов реализации. Только вот к "структурному программированию" он отношения нынче практически не имеет
не убедил
Цитата
В соответствии с данной методологией Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций: - последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы; - ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия; - цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла). В программе базовые конструкции могут быть вложены друг в друга произвольным образом, но никаких других средств управления последовательностью выполнения операций не предусматривается. Повторяющиеся фрагменты программы (либо не повторяющиеся, но представляющие собой логически целостные вычислительные блоки) могут оформляться в виде т. н. подпрограмм (процедур или функций). В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы. При выполнении такой инструкции выполняется вызванная подпрограмма, после чего исполнение программы продолжается с инструкции, следующей за командой вызова подпрограммы. Разработка программы ведётся пошагово, методом «сверху вниз». Сначала пишется текст основной программы, в котором, вместо каждого связного логического фрагмента текста, вставляется вызов подпрограммы, которая будет выполнять этот фрагмент. Вместо настоящих, работающих подпрограмм, в программу вставляются «заглушки», которые ничего не делают. Полученная программа проверяется и отлаживается. После того, как программист убедится, что подпрограммы вызываются в правильной последовательности (то есть общая структура программы верна), подпрограммы-заглушки последовательно заменяются на реально работающие, причём разработка каждой подпрограммы ведётся тем же методом, что и основной программы. Разработка заканчивается тогда, когда не останется ни одной «затычки», которая не была бы удалена. Такая последовательность гарантирует, что на каждом этапе разработки программист одновременно имеет дело с обозримым и понятным ему множеством фрагментов, и может быть уверен, что общая структура всех более высоких уровней программы верна. При сопровождении и внесении изменений в программу выясняется, в какие именно процедуры нужно внести изменения, и они вносятся, не затрагивая части программы, непосредственно не связанные с ними. Это позволяет гарантировать, что при внесении изменений и исправлении ошибок не выйдет из строя какая-то часть программы, находящаяся в данный момент вне зоны внимания программиста.
Не смешивай, пожалуйста, парадигму структурного программирования с ООП
в каком месте я смешал?
Цитата (AndreTM)
"Проектирование сверху вниз" - один из стандартов реализации. Только вот к "структурному программированию" он отношения нынче практически не имеет
не убедил
Цитата
В соответствии с данной методологией Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций: - последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы; - ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия; - цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла). В программе базовые конструкции могут быть вложены друг в друга произвольным образом, но никаких других средств управления последовательностью выполнения операций не предусматривается. Повторяющиеся фрагменты программы (либо не повторяющиеся, но представляющие собой логически целостные вычислительные блоки) могут оформляться в виде т. н. подпрограмм (процедур или функций). В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы. При выполнении такой инструкции выполняется вызванная подпрограмма, после чего исполнение программы продолжается с инструкции, следующей за командой вызова подпрограммы. Разработка программы ведётся пошагово, методом «сверху вниз». Сначала пишется текст основной программы, в котором, вместо каждого связного логического фрагмента текста, вставляется вызов подпрограммы, которая будет выполнять этот фрагмент. Вместо настоящих, работающих подпрограмм, в программу вставляются «заглушки», которые ничего не делают. Полученная программа проверяется и отлаживается. После того, как программист убедится, что подпрограммы вызываются в правильной последовательности (то есть общая структура программы верна), подпрограммы-заглушки последовательно заменяются на реально работающие, причём разработка каждой подпрограммы ведётся тем же методом, что и основной программы. Разработка заканчивается тогда, когда не останется ни одной «затычки», которая не была бы удалена. Такая последовательность гарантирует, что на каждом этапе разработки программист одновременно имеет дело с обозримым и понятным ему множеством фрагментов, и может быть уверен, что общая структура всех более высоких уровней программы верна. При сопровождении и внесении изменений в программу выясняется, в какие именно процедуры нужно внести изменения, и они вносятся, не затрагивая части программы, непосредственно не связанные с ними. Это позволяет гарантировать, что при внесении изменений и исправлении ошибок не выйдет из строя какая-то часть программы, находящаяся в данный момент вне зоны внимания программиста.
или, наоборот, имеет самое непосредственное (и в результате этого мы наблюдаем либо "действие залетевшего дятла", либо игнор исключений с возвратом чуть не в нулевое кольцо...
что?
[vba]
Код
Sub Main() Dim Data
Data = GetData(Params) ' функция получения данных
if not hasData() then msgbox "не удалось получить данные" exit sub end if
Function GetData(Params) ' процесс получения данных ' ошибка при получении данных End Function
[/vba]
Цитата (AndreTM)
или, наоборот, имеет самое непосредственное (и в результате этого мы наблюдаем либо "действие залетевшего дятла", либо игнор исключений с возвратом чуть не в нулевое кольцо...
что?
[vba]
Код
Sub Main() Dim Data
Data = GetData(Params) ' функция получения данных
if not hasData() then msgbox "не удалось получить данные" exit sub end if
nerv, это я так, от нервов Конечно же, при правильном проектировании - ничего такого не присходит. Как и в любом деле - если всё делать "правильно" и "как положено", то и результат будет... но жизнь станет такой пресной
nerv, это я так, от нервов Конечно же, при правильном проектировании - ничего такого не присходит. Как и в любом деле - если всё делать "правильно" и "как положено", то и результат будет... но жизнь станет такой пресной AndreTM
Вход
Регистрация
Напомнить пароль
Автосумма
Часто используемые
ВПР
ЕСЛИ
СУММЕСЛИ
Финансовые
Логические
Текстовые
Даты и времени 
Ссылки и массивы 
Математические
Другие функции
Проверка свойств и значений
Баз данных
Математические
Обработки массивов
Обработки строк
Преобразования типов данных 
Загрузки данных
Работы с файлами
Обработки системных параметров
Обработки цвета
Работы с датами и временем
Преобразования в системы счисления
Финансовые
), или, наоборот, имеет самое непосредственное (и в результате этого мы наблюдаем либо "
