C (또는 일반적으로 절차 적 프로그래밍)를위한 디자인 원칙, 모범 사례 및 디자인 패턴? [닫은]

Question 1

C 프로젝트를 설계하는 동안 따를 수있는 알려진 설계 원칙, 모범 사례 및 설계 패턴이 있습니까? 아니면 일반적으로 절차 적 (명령 적) 프로그래밍에 유용한 설계 원칙이 있습니까?

(저는 '객체 지향 세대'의 자식이며 처음으로 대규모 C 프로젝트를 설계해야합니다.)

Question 2

정보 숨김-Parnas ( Software Fundamentals ) 가지지하는대로 .

헤더 및 가시성의 신중한 관리 :

외부 세계에서 숨길 수있는 소스 파일의 모든 것이 있어야합니다. 문서화 된 외부 인터페이스 만 노출되어야합니다.
노출되는 모든 것은 헤더에 선언됩니다.
해당 헤더는 기능이 필요한 곳 (및 정의 된 곳)에 사용됩니다.
헤더는 자체 포함되어 있습니다. 헤더는 필요한 모든 것을 포함하여 작동하도록 보장하기 때문에 필요할 때 사용하고 '내가 포함해야하는 다른 헤더'에 대해 걱정할 필요가 없습니다. 작업.

헤더는 자체 보호되므로 여러 번 포함 되어도 상관 없습니다.

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

'객체'(일반적으로 구조)에서 작동하도록 함수 세트를 설계하고이를 사용하는 코드에서 구조의 내부를 파고 드는 대신 해당 함수를 사용합니다. 자체 부과 캡슐화로 생각하십시오.

Question 3

나의 세 가지 조언 :

단위 테스트를 작성합니다. 그들은 당신이 진행하면서 당신의 문제에 맞는 디자인에 집중하는 데 도움이 될 것입니다. 미리 명상 된 사고에만 의존하는 것보다 훨씬 낫습니다.
메모리 누수 감지기 (모든 종류의 라이브러리가 있음)를 설치하고 첫날부터 실행하십시오. 프로그램 / 테스트가 종료되는 즉시이 라이브러리가 모든 누출을 인쇄하도록하십시오. 이렇게하면 누출을 도입하자마자 누출을 포착 할 수 있으므로 수리가 훨씬 덜 고통 스럽습니다.
C로 OOP 코드를 작성합니다. 그리 어렵지 않습니다. 메서드 재정의를 에뮬레이션 할 수 있지만 간단한 개체의 에뮬레이션으로 시작하는 것이 좋습니다. 이 간단한 메커니즘조차도 큰 마일리지를 제공 할 수 있습니다.

예를 들면 다음과 같습니다.

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

Question 4

C로 객체 지향 코드를 작성하는 주제를 다루는 ANSI-C를 사용한 Object-Oriented Programming 이라는 제목의 좋은 무료 온라인 책 이 있습니다. "object-oriented C"에 대한 Google 검색 은 또한 많은 다른 장점을 산출합니다. 예와 자원.

프로젝트가 안전에 중요한 경우 MISRA-C 는 좋은 규칙 세트입니다. 주로 임베디드 c를위한 것이지만 다른 영역에서도 유용 할 수 있습니다.

저는 제 자신을 OO 코더라고 생각하고 임베디드 -C로 많은 작업을합니다. 특히 대규모 프로젝트에 대해 제가 드릴 수있는 최선의 조언은 과용하지 말라는 것입니다. ANSI C를 기반으로 완전한 OO 프레임 워크를 만드는 것은 매우 유혹적 일 수 있지만 제대로 작동하려면 많은 시간과 노력이 필요합니다. 더 좋아질수록 실제 프로젝트 에서 작업하는 대신 프레임 워크를 디버깅하는 데 더 많은 시간을 할애하게됩니다 . 명확한 머리와 YAGNI를 잘 이해하고 작업에 접근하십시오 . 행운을 빕니다!

Question 5

OOP는 기술이 아닌 방법론입니다. 그래서 첫 번째 조언은 그것을 절차 적 프로그래밍으로 생각하지 말라는 것입니다.

e. James의 지적에 따르면, 객체 지향 언어를 재창조하거나 그 능력이있는 척하고 싶지는 않습니다. 몇 가지 간단한 원칙을 고수하면 모든 올바른 일을 할 수 있습니다.

모든 것을 시험 운전하십시오.
무엇이 변하는 지 찾아서 캡슐화하십시오.
인터페이스 디자인.