Принципы проектирования, передовой опыт и шаблоны проектирования для C (или процедурного программирования в целом)? [закрыто]

Существуют ли какие-либо известные принципы проектирования, лучшие практики и шаблоны проектирования, которым можно следовать при разработке проекта на языке C? Или полезные принципы проектирования для процедурного (императивного) программирования в целом?

(Я ребенок «объектно-ориентированного поколения», и мне впервые нужно разработать большой проект на C)

Скрытие информации - как придерживается Парнас ( Основы программного обеспечения ).

Тщательное управление заголовками и видимостью:

• Все в исходном файле, что может быть скрыто от внешнего мира, должно быть; должен быть открыт только задокументированный внешний интерфейс.
• Все, что отображается, объявляется в заголовке.
• Этот заголовок используется там, где требуется функциональность (и там, где она определена).
• Заголовок является самодостаточным - когда он вам нужен, вы его используете, и вам не нужно беспокоиться о том, «какие еще заголовки мне также нужно включить», потому что заголовок гарантирует, что он работает, включая все, что ему нужно для его создания. Работа.

• Заголовок является самозащищенным, поэтому не имеет значения, включен ли он несколько раз.

  #ifndef HEADER_H_INCLUDED
  #define HEADER_H_INCLUDED
  ...rest of header contents, including other #include lines if necessary
  #endif /* HEADER_H_INCLUDED */
  

• Создавайте наборы функций для работы с «объектами» (обычно структурами) - и используйте эти функции вместо того, чтобы копаться во внутренностях структуры в коде, который ее использует. Думайте об этом как о добровольной инкапсуляции.

Мои три совета:

• Напишите модульные тесты. Они помогут вам сконцентрироваться на дизайне, который решает вашу проблему в дальнейшем. Намного лучше, чем полагаться (исключительно) на заранее продуманное мышление.
• Установите и запустите детектор утечки памяти (есть все виды библиотек) с первого дня. Попросите эту библиотеку распечатать все утечки сразу после выхода из программы / тестов. Это позволит вам обнаружить утечку сразу же после ее введения, что сделает ее устранение менее болезненным.
• Напишите код ООП на C. Не так уж и сложно. Хотя можно имитировать переопределение метода, я предлагаю начать с эмуляции простых объектов. Даже этот простой механизм может дать вам большой пробег.

Вот пример:

typedef struct Vector {
  int size;
  int limit;
  int* ints; 
} Vector;

Vector* Vector_new() {
  Vector* res = (Vector*) malloc(sizeof(Vector));
  res->limit = 10;
  res->size = 0;
  res->ints = (int*) malloc(sizeof(int) * res.limit);

  return res;
}


void Vector_destroy(Vector* v) {
  free(v->ints);
  free(v);
}

void Vector_add(Vector* v, int n) {
  if(v->size == v->limit) {
    v->limit = v->limit * 2 + 10;
    v->ints = realloc(v->ints, v->limit);     
  }

  v->ints[v->size] = n;
  ++v->size;
}

int Vector_get(Vector* v, int index) {
  if(index >= 0 && index < v->size)
    return v->ints[index];

  assert false;
}

Существует хорошая бесплатная онлайн-книга под названием « Объектно-ориентированное программирование с помощью ANSI-C» , в которой рассматривается тема написания объектно-ориентированного кода на C. Поиск в Google «объектно-ориентированного C» также дает ряд других полезных результатов. примеры и ресурсы.

Если ваш проект критичен к безопасности, MISRA-C - хороший набор правил. Он предназначен в основном для встроенного c, но может быть полезен и в других областях.

Я считаю себя объектно-ориентированным кодером и много работаю со встроенным C. Лучший совет, который я могу дать, особенно для крупных проектов, - не переусердствовать. Создание полной объектно-ориентированной структуры на основе ANSI C может быть очень заманчивым, но для того, чтобы сделать это правильно, требуется много времени и усилий. Чем красивее вы станете, тем больше времени вы потратите на отладку своего фреймворка вместо работы над реальным проектом. Подойдите к задаче с ясной головой и твердым знанием ЯГНИ . Удачи!

ООП - это методология, а не технология. Итак, мой первый совет - перестаньте думать об этом как о процедурном программировании.

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

1. Тест-драйв все.
2. Найдите то, что меняется, и инкапсулируйте это.
3. Дизайн для интерфейсов.