Разработчики Linux используют структурный подход для разработки ядра. Это значит, что крупная задача разбивается мелкие блоки, которые собираются в иерархические структуры. Такой подход был предложен более 40 лет назад.
Недостатки структурной парадигмы
Уже к концу 80-х годов многим асам программирования стали понятны главные недостатки структурного подхода:
- затруднено повторное использование кода;
- использование глобальных переменных приводит к появлению трудно вылавливаемых ошибок;
- оператор goto резко снижает читаемость кода;
- «восходящее» программирование сильно осложнено;
- раздельное сосуществование данных и кода приводит к сложностям при внесении в программу изменений;
- и т.д.
В попытке решить эти проблемы, в начале 90-х возникает объектно-ориентированный подход к программированию, который становится со временем доминирующей парадигмой в разработке крупных промышленных программ.
Linux становится объектно-ориентированным
Программисты из индийской лаборатории Centre for Development of Advanced Computing любят Linux, но не любят структурный подход, поэтому они взяли Linux и проделали с ним две вещи:
1. Сначала они «почистили» код ядра, по возможности избавившись от глобальных переменных. По мнению специалистов, если разработчики основной ветки не станут делать то же самое, Linux столкнется с проблемой сопровождения кода уже в ближайшие 2-3 года.
2. Программисты внимательно изучили код ядра и выяснили, что большая часть ядра состоит из драйверов устройств. Тогда они решили, что часть драйверов можно переписать с применением объектно-ориентированного подхода. Для этого был создан специальный фреймворк, а для демонстрации его работоспособности программистами был переписан сетевой драйвер Ethernet (ne2k_pci.c). Новый драйвер был написан не на традиционном для ядра Linux языке программирования С, а на его объектно-ориентированной версии — C++. В результате программистам удалось сделать код проще и безопасней, тогда как общее снижение производительности из-за перехода на ООП составило всего около 2%.
Свою разработку индусы назвали Minimalistic Object Oriented Linux (MOOL). Переработанное ядро и фрэймворк для написания драйверов на C++ можно свободно (GPL) загрузить с сайта лаборатории.
Для демонстрации работоспособности ядро MOOL было интегрировано в состав дистрибутива Bharat Operating System Solution (BOSS), который тоже доступен для загрузки.
старые С — кодеры, очень не согласны с этим, мода С++ и С# уже добралась и до ядра Linux! Ждем ответа отца-основателя?
P.S. «В результате программистам удалось сделать код проще и безопасней, тогда как общее снижение производительности из-за перехода на ООП составило всего около 2%." — об этом говорят пока только сами разрабы этой фичи, а что думают независимые эксперты?
"Структурный подход - это элементарная дедукция, Ватсон"
Хотя лучше - применять в построении кода: Индукцию (лат. inductio — наведение) — процесс логического вывода на основе перехода от частного положения к общему. Индуктивное умозаключение связывает частные предпосылки с заключением не строго через законы логики, а скорее через некоторые фактические, психологические или математические представления.
Объективным основанием индуктивного умозаключения является всеобщая связь явлений в природе.
А Торвальдс давно сказал, что С++ — говно. В общем-то он прав. Все те же грабли с памятью, переполнением буфера и некорректными указателями. Только еще производительность падает и синтаксис придурочный. ;)
Эксперды в недоумении.
Нету такого. Есть восходящий и нисходящий стили программирования. При нисходящем сначала описывается проблема и разбивается на подзадачи, которые тоже разбиваются на подзадачи и т.д. При восходящем сначала пишутся составные части (подзадачи), которые потом объединяются в более крупные куски кода.
Нет такого? Разве:) :
1. С рекурсией тесно связана математическая индукция: она является естественным способом доказательства свойств функций на натуральных числах, рекурсивно заданных через свои меньшие значения.
[бла-бла-бла]
Примеры рекурсии в математике:
[бла-бла-бла]
Пожалуйста, не надо простыней копипаста в комментариях, достаточно ссылки. Но я не понял, причем здесь уже рекурсия? Что Вы с темы на тему прыгаете? Сначала говорили о том, что в программировании не используется термин индукция, а используются понятия восходящего и нисходящего программирования. Да и сама индукция непонятно откуда вылезла. Вроде, речь первоначально шла о попытке добавить ООП в процесс разработки ядра.
Математическая индукция — широко используется в функциональном программировании и в языках данной парадигмы! Надеюсь, что так устроит Вас? Это если кратко, а частичная копипаста была для лентяев!
1. «Совмещение» данных с кодом приводит к трудностям при создании обобщенных алгоритмов, затрудняя повторное использование.
2. Проблема глобальных переменных решается использованием модулей. ООП просто заменяет глобальные переменные на непонятно откуда унаследованные.
3. Размазывание алгоритма по куче мелких методов и классов гораздо запутаннее чем любой GOTO. Который, кстати, в структурном подходе и не используется.
4. «Восходящее» программирование ничем не проще при использовании ООП. Придумать общеполезную процедуру куда легче чем общеполезный класс.
Не являюсь фанатом ООП, скорее наоборот. Но ради восстановления справедливости замечу:
Не заменяет, а инкапсулирует их. И случайно изменить их значение где-то не там становится невозможно.
Поэтому и были придуманы интерфейсы. Пользователю классов не нужно знать что и где размазано, он должен только ориентироваться в публичных интерфейсах. Разработчику же классов не запутаться позволяют паттерны проектирования. А устроить винегрет при желании можно в любой парадигме.
Этим и отличаются говнопогромисты от асов. Первые бездумно создают пачку классов по любому поводу, вторые следуют совету создавать только классы с высоким уровнем абстракции.
Но лично я считаю, что преимущества ООП сильно переоценены. Это скорее модно, чем полезно. Бонусы от использования объектного подхода становятся заметными только при разработке крупных и сверхкрупных проектов прикладного характера. Для ядра операционной системы использование ООП является лишь способом потерять процентов 20 производительности и не получить ничего взамен.
Вот поэтому, только чистый С — только ХАРДКОР! Производительность на уровне, да и в плане безопасности не очень плохо, того чего нет в языках, типа: С++!