Dalam sebagian besar aplikasi besar kami, kami biasanya hanya memiliki beberapa lokasi untuk "konstanta":
- Satu kelas untuk GUI dan kontestan internal (judul Halaman Tab, judul Kotak Grup, faktor perhitungan, enumerasi)
- Satu kelas untuk tabel dan kolom basis data (bagian ini menghasilkan kode) plus nama yang dapat dibaca untuk mereka (ditetapkan secara manual)
- Satu kelas untuk pesan aplikasi (logging, kotak pesan, dll)
Konstanta biasanya dipisahkan menjadi struct yang berbeda di kelas-kelas tersebut. Dalam aplikasi C ++ kami, konstanta hanya didefinisikan dalam file .h dan nilai ditetapkan dalam file .cpp.
Salah satu keuntungannya adalah bahwa semua string dll berada di satu tempat pusat dan semua orang tahu di mana menemukannya ketika sesuatu harus diubah.
Ini terutama sesuatu yang tampaknya disukai manajer proyek ketika orang datang dan pergi dan dengan cara ini semua orang dapat mengubah hal-hal sepele tanpa harus menggali ke dalam struktur aplikasi.
Juga, Anda dapat dengan mudah mengubah judul Kotak Grup / Halaman Tab serupa dll sekaligus. Aspek lain adalah Anda hanya dapat mencetak kelas itu dan memberikannya kepada non-programmer yang dapat memeriksa apakah teksnya intuitif, dan apakah pesan kepada pengguna terlalu rinci atau terlalu membingungkan, dll.
Namun, saya melihat kerugian tertentu:
- Setiap kelas tunggal sangat erat dengan kelas konstanta
- Menambah / Menghapus / Mengganti Nama / Memindahkan konstanta membutuhkan kompilasi ulang setidaknya 90% dari aplikasi (Catatan: Mengubah nilai tidak, setidaknya untuk C ++). Dalam salah satu proyek C ++ kami dengan 1500 kelas, ini berarti sekitar 7 menit waktu kompilasi (menggunakan header yang dikompilasi; tanpa mereka itu sekitar 50 menit) ditambah sekitar 10 menit menghubungkan ke perpustakaan statis tertentu.
- Membangun rilis yang dioptimalkan dengan kecepatan melalui Visual Studio Compiler membutuhkan waktu hingga 3 jam. Saya tidak tahu apakah jumlah besar dari hubungan kelas adalah sumber tetapi mungkin juga begitu.
- Anda didorong ke string sementara yang langsung dikodekan ke dalam kode karena Anda ingin menguji sesuatu dengan sangat cepat dan tidak ingin menunggu 15 menit hanya untuk tes itu (dan mungkin setiap yang berikutnya). Semua orang tahu apa yang terjadi pada "Saya akan memperbaikinya nanti".
- Menggunakan kembali kelas di proyek lain tidak selalu mudah (terutama karena kopling ketat lainnya, tetapi penanganan konstanta tidak membuatnya lebih mudah.)
Di mana Anda menyimpan konstanta seperti itu? Juga argumen apa yang akan Anda bawa untuk meyakinkan manajer proyek Anda bahwa ada konsep yang lebih baik yang juga sesuai dengan keuntungan yang tercantum di atas?
Jangan ragu untuk memberikan jawaban C ++ - spesifik atau independen.
PS: Saya tahu pertanyaan ini agak subyektif tapi saya jujur tidak tahu tempat yang lebih baik daripada situs ini untuk pertanyaan semacam ini.
Perbarui proyek ini
Saya punya berita tentang waktu kompilasi:
Mengikuti posting Caleb dan gbjbaanb, saya membagi file konstanta saya menjadi beberapa file lain ketika saya punya waktu. Saya juga akhirnya membagi proyek saya menjadi beberapa perpustakaan yang sekarang mungkin lebih mudah. Kompilasi ini dalam mode rilis menunjukkan bahwa file yang dihasilkan secara otomatis yang berisi definisi basis data (tabel, nama kolom, dan lainnya - lebih dari 8000 simbol) dan membangun hash tertentu menyebabkan waktu kompilasi yang sangat besar dalam mode rilis.
Menonaktifkan pengoptimal MSVC untuk perpustakaan yang berisi konstanta DB sekarang memungkinkan kami untuk mengurangi total waktu kompilasi Proyek Anda (beberapa aplikasi) dalam mode rilis dari hingga 8 jam menjadi kurang dari satu jam!
Kami belum mengetahui mengapa MSVC kesulitan mengoptimalkan file-file ini, tetapi untuk saat ini perubahan ini mengurangi banyak tekanan karena kami tidak lagi harus bergantung hanya pada build malam saja.
Fakta itu - dan manfaat lainnya, seperti kopling yang kurang rapat, penggunaan kembali yang lebih baik, dll. - juga menunjukkan bahwa menghabiskan waktu untuk memisahkan "konstanta" bukanlah ide yang buruk ;-)
Pembaruan2
Karena pertanyaan ini masih mendapat perhatian:
Inilah yang telah saya lakukan dalam beberapa tahun terakhir:
Letakkan setiap konstanta, variabel, dll, persis di dalam cakupan yang relevan untuknya: Jika Anda menggunakan konstanta hanya dalam satu metode, tidak apa-apa untuk mendefinisikannya dalam metode itu. Jika satu kelas tertarik, biarkan itu sebagai detail implementasi pribadi dari kelas itu. Hal yang sama berlaku untuk ruang nama, modul, proyek, ruang lingkup perusahaan. Saya juga menggunakan pola yang sama untuk fungsi pembantu dan sejenisnya. (Ini mungkin tidak berlaku 100% jika Anda mengembangkan kerangka kerja publik.)
Melakukan peningkatan reusabilitas, pengujian, dan pemeliharaan ini hingga pada tingkat di mana Anda tidak hanya menghabiskan lebih sedikit waktu untuk kompilasi (setidaknya dalam C ++), tetapi juga lebih sedikit waktu untuk memperbaiki bug, yang membuat Anda lebih banyak waktu untuk benar-benar mengembangkan fitur baru. Pada saat yang sama, mengembangkan fitur-fitur ini akan berjalan lebih cepat karena Anda dapat menggunakan kembali kode lebih mudah. Ini melebihi keuntungan apa pun yang mungkin dimiliki oleh file konstanta pusat.
Lihatlah terutama Prinsip Segregasi Antarmuka dan Prinsip Tanggung Jawab Tunggal jika Anda ingin tahu lebih banyak.
Jika Anda setuju, pilih jawaban Caleb karena pembaruan ini pada dasarnya lebih bersifat umum tentang apa yang dikatakannya.