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

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

(Я ребенок "объектно-ориентированного поколения" и должен разработать большой проект C в первый раз)

5 85
javascript class-design design-patterns solid-principles

5 ответов:

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

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

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

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

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

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

58

есть хорошая, бесплатная, онлайн книга, под названием объектно-ориентированное программирование с ANSI-C, который охватывает тему написания объектно-ориентированного кода в C. A поиск в google для "объектно-ориентированного C" также дает ряд других положительных примеров и ресурсов.

Если ваш проект имеет решающее значение для безопасности,МИСРА-С хороший набор правил. Он предназначен в основном для встроенного c, но может быть полезен в других областях, как что ж.

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

20

мои три указания:

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

вот пример:

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

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;
}
19

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

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

  1. тест-драйв все.
  2. найти то, что меняется и инкапсулировать его.
  3. дизайн межфазные границы.
6

стандарт кодирования SEI CERT C обеспечивает хороший набор правил и общих хороших практик а также вещи, которые вы должны стараться избегать использования.

4