Prinsip Desain, Praktik Terbaik dan Pola Desain untuk C (atau Pemrograman Prosedural secara umum)? [Tutup]

Question 1

Adakah prinsip desain, praktik terbaik, dan pola desain yang diketahui yang dapat diikuti seseorang saat merancang proyek C? Atau prinsip desain yang berguna untuk pemrograman prosedural (imperatif) secara umum?

(Saya anak dari 'generasi berorientasi objek' dan harus merancang proyek C besar untuk pertama kalinya)

Question 2

Menyembunyikan informasi - seperti yang didukung oleh Parnas ( Software Fundamentals ).

Manajemen header dan visibilitas yang cermat:

Segala sesuatu di file sumber yang dapat disembunyikan dari dunia luar harus; hanya antarmuka eksternal yang terdokumentasi yang harus diekspos.
Segala sesuatu yang diekspos dideklarasikan di header.
Header itu digunakan di mana fungsionalitas dibutuhkan (dan di mana ia didefinisikan).
Header itu berdiri sendiri - ketika Anda membutuhkannya, Anda menggunakannya, dan Anda tidak perlu khawatir tentang 'header lain apa yang juga harus saya sertakan' karena header memastikannya berfungsi dengan memasukkan apa pun yang diperlukan untuk membuatnya kerja.

Header dilindungi sendiri - jadi tidak masalah jika disertakan beberapa kali.

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

Rancang set fungsi untuk bekerja pada 'objek' (biasanya struktur) - dan gunakan fungsi tersebut daripada melihat-lihat bagian dalam struktur dalam kode yang menggunakannya. Anggap saja sebagai enkapsulasi yang dipaksakan sendiri.

Question 3

Tiga saran saya:

Tulis tes unit. Mereka akan membantu Anda menemukan desain yang sesuai dengan masalah Anda saat Anda melanjutkan. Jauh lebih baik daripada mengandalkan (hanya) pada pemikiran yang telah dimeditasi sebelumnya.
Memiliki detektor kebocoran memori (ada semua jenis pustaka di luar sana) terpasang dan berjalan sejak hari pertama. Mintalah perpustakaan ini mencetak semua kebocoran segera setelah program / tes keluar. Ini akan memungkinkan Anda untuk mengetahui kebocoran segera setelah Anda memasukkannya, sehingga membuat perbaikannya menjadi tidak terlalu menyakitkan.
Tulis kode OOP di C. Tidak terlalu sulit. Meskipun dimungkinkan untuk meniru metode penimpaan, saya sarankan Anda mulai dengan emulasi objek sederhana. Bahkan mekanisme sederhana ini dapat memberi Anda jarak tempuh yang luar biasa.

Berikut contohnya:

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

Ada buku online yang bagus dan gratis, berjudul Pemrograman Berorientasi Objek Dengan ANSI-C , yang membahas topik penulisan kode berorientasi objek di C. Penelusuran Google untuk "C berorientasi objek" juga menghasilkan sejumlah barang lainnya. contoh dan sumber daya.

Jika proyek Anda kritis terhadap keselamatan, MISRA-C adalah seperangkat aturan yang baik. Ini sebagian besar ditujukan untuk c tertanam, tetapi dapat berguna di area lain juga.

Saya menganggap diri saya seorang pembuat kode OO, dan saya melakukan banyak pekerjaan dengan embedded-C. Nasihat terbaik yang bisa saya berikan, terutama untuk proyek-proyek besar, adalah jangan berlebihan. Membuat kerangka kerja OO lengkap di atas ANSI C bisa sangat menggoda, tetapi membutuhkan banyak waktu dan upaya untuk membuatnya benar. Semakin menarik Anda, semakin banyak waktu yang Anda habiskan untuk men-debug kerangka kerja Anda daripada mengerjakan proyek sebenarnya . Dekati tugas dengan pikiran yang jernih, dan pemahaman YAGNI yang baik dan solid . Semoga berhasil!

Question 5

OOP adalah metodologi bukan teknologi. Jadi saran pertama saya adalah berhenti menganggapnya sebagai pemrograman prosedural.

Untuk poin e.James, Anda tidak ingin mencoba dan menciptakan kembali bahasa berorientasi objek atau berpura-pura bahwa Anda memiliki kemampuannya. Anda masih dapat melakukan semua hal yang benar dengan berpegang pada beberapa prinsip sederhana:

Uji coba semuanya.
Temukan apa yang memvariasikan dan merangkumnya.
Desain antarmuka.