Какова архитектура крупных приложений на низкоуровневых языках?

Что из себя представляет дизайн крупных приложений написанных на си?

Переходя из ООП языков где у меня есть классы, мне сложно понять, как разрабатываются большие программы на си.
  • Вопрос задан
  • 954 просмотра
Пригласить эксперта
Ответы на вопрос 4
MarcusAurelius
@MarcusAurelius
автор Impress Application Server для Node.js
ООП это не архитектура, а парадигма. Скорее всего Вы хотели спросить, какие есть паттерны проектирования в парадигмах процедурного и структурного программирования. Перечислю кратко: модули (структурные блоки, библиотеки, часто построенные в иерархическую систему при помощи dependency injection), интерфейсы (наборы экспортируемых функций, которые видны снаружи модуля), шаблоны (функции, абстрагированные от типов данных, при помощи которых парадигма обобщенного программирования позволяет порождать типизированные реализации), слои (как ни странно, но до ООП тоже были абстракции, они реализовывались при помощи принципа разделения модулей на слои, т.е. группы модулей, реализующие более низкоуровневые или более высокоуровневые задачи, программирование обычно начинается с самого высокого слоя абстракций, из него можно использовать только вызовы на 1 слой ниже, но не на 2 слоя, т.е. нельзя смешивать абстракции и пропускать слои, обращаясь, грубо говоря, от нажатия кнопки сразу к кластеру на диске), заглушки (должны Вам должны быть известны, это функции и модули без реализации, необходимые чтобы запускать и отлаживать еще не дописанную программу, они могут выводить вызовы к ним на экран или в логи, а состоять только из возврата правдоподобных но не настоящих данных). Так же есть много паттернов структур данных, которые тоже очень сильно упрощают жизнь, если выбрать определенную их реализацию для своего проекта и придерживаться принципа однородности структур данных, например, не использовать две разные реализации двусвязных списков в одной программе (или модуле). Структуры данных вполне заменяют объекты, более того, работают они несравнимо быстрее, не создают проблемы неоднозначности моделирования, как в ООП например, когда Вы не можете решить, где должен находиться метод "сесть" у "жопы", у "стула" или у их общего контейнера "мир", в котором это происходит. Распространенные структуры данных: набор полей, список (в т.к. односвязный, двусвязный, циклический и т.д.), стек, дерево (тоже может быть от односвязного до пятисвязного с вариациями), множество, очередь, ассоциативный массив и хеш-таблица. Все, устал писать, рекомендую почитать Дэйкстру, Вирта, Кнута. А смириться с отсутствием ООП может помочь занятная статья в стиле холиварного срача: blogerator.ru/page/oop_why-objects-have-failed
Ответ написан
Комментировать
jcmvbkbc
@jcmvbkbc
"I'm here to consult you" © Dogbert
Да так же, как и в С++. Вместо классов -- структуры данных. Вместо интерфейсов -- структуры с указателями на функции. Вместо шаблонов -- макросы. Наследование -- структуры содержащие поля-структуры.
Ответ написан
uvelichitel
@uvelichitel
habrahabr.ru/users/uvelichitel
Почитайте заголовочные .h файлы хорошо структурированных opensource проектов. Я на Plan9 учусь.
Ответ написан
Комментировать
@Eddy_Em
Это с какого перепугу С стал низкоуровневым языком?
А архитектура простая: разделяем по файлам, чтобы каждый файл не больше пары тысяч строк занимал (иначе читать неудобно).
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы