Чем лучше использование функций для выполнения программы?
К примеру:
#include
void F0() {
printf("Hello World") ;
}
int main() {
F0();
getchar();
return 0;
}
Ведь можно в main выполнить команды ?
Ответы
Ответ 1
Функции служат структурированию вашей программы.
Если вам качество программы неважно (например, программа простая, или вы не собираетес
её дальше разрабатывать и поддерживать), во многих случаях без функций можно и обойтись (важный контрпример: рекурсия).
Но если вы хотите сделать код легко читаемым, понятным, поддерживаемым, расширяемым
то вам нужно его структурировать: разделить на осмысленные части, и дать им имя. Это и есть ваши функции.
Заметьте, что вы в любом случае пользуетесь библиотечными функциями, наподобие getchar(): разработчики библиотеки уже структурировали её для вас.
Функции — не единственный метод структурирования программы. Например, ещё одно популярное, более мощное средство структурирования — классы.
Ответ 2
divide et impera
Есть такое понятие как "декомпозиция", т.е. разделение целого на части. Для элементарны
ситуаций разделение не обязательно. Но когда программа становится большой, для того чтобы проще было ей управлять и развивать её, приходится делить на более мелкие сущности, давая им в то же время говорящие имена.
Ответ 3
Да все команды можно выполнить в одной функции main().
Но использование функций позволяет повторно использовать одинаковые блоки исходного кода. Улучшает читаемость исходного кода.
Ответ 4
Причин разделения кода на функции несколько.
Повторное использование.
Довольно часто требуется многократное использование одной функции в разных частя
программы. Было бы крайне не разумно писать один и тот же код повторно. Тем более, что в случае изменений их придется вносить в каждый фрагмент. А если вынести функцию в отдельный файл, то можно использовать ее даже в нескольких проектах.
Читаемость.
Читаемость кода очень важная характеристика программы. Даже если программа небольша
и написана одним человеком разделение на функции с понятными именами позволяет довольн
быстро понять суть происходящего даже после длительного перерыва работы с кодом. А если код ведут несколько программистов, то читаемость кода очень сильно влияет на скорость и качество разработки, и как следствие, на итоговый результат.
Качество, отладка, тестирование и т.д.
Разделение крупной системы на отдельные части (модули) является одним из базовы
принципов проектирования не только в программировании. Связано это со многими вещами
Работать с небольшими частями проще, их легче заменить и отладить. Есть понятие юнит-тестов, применимое к функциям. Более того, в различных языках программирования есть свои аспекты применения функций, дающих те или иные преимущества. Например template в C++ или замыкания в JavaScript.
А вообще советую почитать книгу С.Макконнелла "Совершенный код" или нечто подобное, с общими аспектами программирования.
Ответ 5
Смотрю, выше привели основную причину -- декомпозиция программы на части. Но у функций есть и другие применения.
Например, полиморфизм. Пример: я пишу функцию вывода на экран некоторого объекта
Одна функция делает это красиво но медленно -- подойдёт когда времени много, втора
быстро но некрасиво -- подходит для сценария когда мы быстро тащим или масштабируе
объект. Для этого делаем прототип функции (определяет набор параметров и возвращаемое значение), и реализуем две функции, соответствующие этому прототипу. Указатель на функцию у нас содержит текущий способ рисования -- и мы можем вызывать функцию рисования, не зная даже на какую конкретно из них он указывает.
Дальше -- мы можем иметь массив таких указателей на функции, с одним и тем же прототипом
Смысл -- некоторые из них просто рисуют, другие работают как фильтры. Например, фильтр
подсвечивающий точки объекта, за которые можно "потянуть". Опять же, мы можем вызывать все функции из массива по порядку -- чтобы отрисовать объект со всеми фильтрами, и вызывающий их код не знает что они делают.
Ответ 6
декомпозиция
выделение функций в отдельные сущности позволяет и работать с ними как с компонентами
отдельно тестировать, отлаженная функция должна работать одинаково во всех ваших (и вашей конторы) программах, и использовать ее можно одновременно во всех 100500 программах, запущенных на суперкластере
наследование
наборы готовых функций собираются в библиотеки, распространяются и применяются тысячам
программистов по всему миру десятки лет (BLAS/LAPACK/libc/WinAPI), или продаются как самостоятельный продукт -- любая ОС является библиотекой функций, см. \Windows\System\*.dll /lib/*.so, и коммерческие библиотеки компонент
инкапсуляция
типичная функция sin(), вы знаете ее назначение, обычно типы входных/выходных данны
(область/множество определения, область/множество значений), но понятия не имеете, ка
она устроена внутри: как вызов спецкоманды процессора, поиск по таблице, сумма ряда
запрос к внешней мат.системе или отладочная заглушка возвращающая заданное значени
незавимо от входных данных. Вы можете заменять реализацию функции sin() в любой момент без перекомпиляции или даже перезапуска программы. Вы даже можете придумать собственный метод быстрого приближенного вычисления синуса, и протестировать его работу как с вашими, так и с любыми чужими программами, не имея доступа к исходному коду этих программ.
некоторые программные продукты, например распознаватель Abbyy или ядро САПР, продаютс
просто в виде кучи скомпилированных функций -- 100 рублей штучка, 300 штук кучка, оптовым покупателям документация бесплатно
интерфейс
часто тяжелые коммерческие пакеты САПР,аналитики,расчетов и разнообразное оборудовани
поставляются опцией или в комплекте с SDK-библиотекой, собранной из интерфейсных функций
в документации описаны их назначение, применение, и типы/диапазоны входных/выходных данных, но сами функции идут в виде машинного кода без исходников (только кучка .h файлов с перечнем extern void to(); extern double se(int,void*), и пара .dll)
полиморфизм
функция bubblesort() может быть описана в общем виде, сортируя данные любых даж
еще не существующих типов, хранящиеся в любом упорядоченном контейнере (например сортироват
слонопотамов в сепулькарии), при условии что для данных существует операция сравнения, а для контейнера -- передача сообщения двум соседним элементам "сравнитесь между собой" и их перестановка местами (обычно исправляются ссылки кто за кем стоит, но как показывает практика медосмотров даже пятисвязные хешированные списки ничего не гарантируют)
оптимизация
оптимизирующий компилятор может сам решить, когда оформить функцию в виде отдельног
блока кода c call/ret вызовом, а когда памяти хватает, межмодульных вызовов нет, и можн
развернуть код функции в каждом месте использования, и прогнать по результату всю батарею оптимизаторов, в сишных программах добавляйте inline подсказывая компилятору что этот код можно подставлять а не вызывать, в особо клинических случаях вместо используйте вместо функций макросы (и шаблоны ?)
Комментариев нет:
Отправить комментарий