Principi di progettazione, migliori pratiche e modelli di progettazione per C (o programmazione procedurale in generale)? [chiuso]

Esistono principi di progettazione, best practice e schemi di progettazione noti che è possibile seguire durante la progettazione di un progetto C? O utili principi di progettazione per la programmazione procedurale (imperativa) in generale?

(Sono figlio della 'generazione orientata agli oggetti' e devo progettare un grande progetto C per la prima volta)

Nascondere le informazioni - come proposto da Parnas ( Software Fundamentals ).

Gestione attenta di intestazioni e visibilità:

• Tutto in un file sorgente che può essere nascosto al mondo esterno dovrebbe essere; dovrebbe essere esposta solo l'interfaccia esterna documentata.
• Tutto ciò che è esposto viene dichiarato in un'intestazione.
• Quell'intestazione viene utilizzata dove è necessaria la funzionalità (e dove è definita).
• L'intestazione è autonoma: quando ne hai bisogno, la usi e non devi preoccuparti di `` quali altre intestazioni devo includere anche io '' perché l'intestazione garantisce che funzioni includendo tutto ciò di cui ha bisogno per realizzarla lavoro.

• L'intestazione è autoprotetta, quindi non importa se viene inclusa più volte.

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

• Progetta insiemi di funzioni per lavorare su "oggetti" (di solito strutture) - e usa quelle funzioni piuttosto che frugare all'interno della struttura nel codice che la sta usando. Consideralo come un incapsulamento autoimposto.

I miei tre consigli:

• Scrivi unit test. Ti aiuteranno a concentrarti su un design che si adatta al tuo problema mentre procedi. Molto meglio che affidarsi (esclusivamente) al pensiero pre-meditato.
• Avere un rilevatore di perdite di memoria (ci sono tutti i tipi di librerie là fuori) installato e funzionante dal primo giorno. Fai in modo che questa libreria stampi tutte le perdite non appena il programma / i test sono terminati. Questo ti permetterà di catturare una perdita non appena la introduci, rendendo così la sua riparazione molto meno dolorosa.
• Scrivi il codice OOP in C. Non è così difficile. Sebbene sia possibile emulare l'override del metodo, suggerisco di iniziare con l'emulazione di oggetti semplici. Anche questo semplice meccanismo può darti un ottimo chilometraggio.

Ecco un esempio:

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

Esiste un buon libro online gratuito, intitolato Programmazione orientata agli oggetti con ANSI-C , che tratta l'argomento della scrittura di codice orientato agli oggetti in C. Una ricerca su Google per "C orientato agli oggetti" produce anche una serie di altri buoni esempi e risorse.

Se il tuo progetto è critico per la sicurezza, MISRA-C è un buon insieme di regole. È inteso principalmente per embedded c, ma può essere utile anche in altre aree.

Mi considero un programmatore OO e lavoro molto con embedded-C. Il miglior consiglio che posso dare, soprattutto per i grandi progetti, è di non esagerare. La creazione di un framework OO completo su ANSI C può essere molto allettante, ma richiede molto tempo e impegno per farlo bene. Più sei appassionato, più tempo passerai a eseguire il debug del framework invece di lavorare sul progetto reale . Affronta il compito con la mente lucida e una buona e solida conoscenza di YAGNI . Buona fortuna!

OOP è una metodologia non una tecnologia. Quindi il mio primo consiglio è smettere di pensarlo come programmazione procedurale.

Per quanto riguarda il punto di vista di James, non vuoi provare a ricreare un linguaggio orientato agli oggetti o fingere di averne le capacità. Puoi ancora fare tutte le cose giuste attenendoti ad alcuni semplici principi:

1. Prova tutto.
2. Trova ciò che varia e incapsulalo.
3. Progettare per interfacce.