Membagi menjadi file - berapa banyak membelah?

9

Jika saya katakan saya memiliki kerangka entitas hierarkis, bukan model komponen. Sesuatu seperti:
(Ya, ini dibuat-buat)

Weapon-> Gun-> AutomaticGun-> MP44
Atau, lebih dari contoh klasik:
Entity-> MovableEntity-> Enemy-> WalkingEnemy

Seberapa jauh Anda akan membagi file sumber / header untuk keterbacaan dan organisasi? Apakah yang terbaik adalah melakukan sesuatu seperti Entity.cpp, MovableEntity.cpp, Enemy.cpp, dll. Atau apakah pendekatan seperti Entity.cpp [berisi Entity dan MovableEntity] dan Enemy.cpp [berisi Enemy dan WalkingEnemy] lebih baik? (Atau dengan cara yang lebih agnostik dalam bahasa, file Musuh dan file Entitas vs file untuk setiap kelas?)
Juga, apakah ini akan memengaruhi selain pembacaan dan organisasi?

c++ file

— Bebek Komunis
sumber

1

Nitpicky, tapi saya rasa language-agnosticini bukan tag yang tepat karena sangat tergantung pada bahasa yang Anda gunakan untuk efek samping.

— Tetrad

Poin bagus, saya pikir saya bisa retag.

— The Communist Duck

12

Ini sepenuhnya masalah preferensi. Namun, saya pribadi percaya yang terbaik adalah berbuat salah di sisi lebih banyak file. Java memerlukan satu kelas per file , dengan nama file yang sama dengan nama kelas, misalnya; mereka melakukan ini dengan kebijakan untuk menegakkan praktik baik ini (meskipun Anda dapat memiliki subclass yang pada dasarnya menyiasati ini).

Selain itu, sistem kontrol sumber cukup bagus untuk menggabungkan perubahan dalam file, tetapi tidak terlalu merepotkan jika Anda hanya bekerja di file yang benar-benar terpisah. Anda juga dapat lebih mudah melihat siapa yang mengubah kelas mana. Katakanlah pengembang lain membuat perubahan pada file AllEntities.h; Anda tidak tahu persis entitas apa (atau entitas) yang dia ubah sampai Anda membuka file dan melihat output diff.

Sangat bagus untuk mengelompokkan struct kecil dan enum yang terkait dengan kelas dalam file satu kelas , meskipun. Jika Anda memiliki enum yang hanya digunakan oleh satu kelas, mengapa membaginya menjadi file sendiri? Taruh saja bersama-sama. Tetapi jika itu digunakan oleh kelas lain (yaitu anggota kelas lain adalah tipe enum ini), saat itulah saatnya untuk memberikan file sendiri.

— Ricket
sumber

Sepakat. Kompleksitas tipe Anda pasti harus menjadi faktor. Jika bahasa Anda mendukung kelas parsial (atau jika implementasi anggota dapat diatur mirip dengan C ++), maka saya bahkan akan merekomendasikan memecah jenis yang sangat kompleks menjadi beberapa file. Misalnya, jika ada antarmuka (besar) yang harus diterapkan oleh kelas Anda, tetapi kodenya cukup generik dan tidak terlalu relevan dengan yang lain, Anda bisa memecah kode itu menjadi file terpisah / kelas parsial. Untuk tipe enum, saya pikir Anda bisa lolos dengan menempatkan semua enum untuk namespace yang diberikan dalam satu file.

— Mike Strobel

1

Tidak mengelompokkan enum Anda berarti mengubah nilai tunggal akan menyebabkan kompilasi ulang setiap file yang menggunakan enum di namespace itu?

— The Communist Duck

Yah, itu benar-benar tergantung pada bahasanya, tapi ya, itu pasti bisa memiliki efek itu. Ini tidak benar-benar masalah bagi saya, karena saya mengembangkan terutama di C # (tidak ada kompilasi file-by-file), tetapi bisa bermasalah di C ++ dan bahasa lainnya. Seperti biasa, ada faktor-faktor khusus bahasa yang perlu dipertimbangkan, dan itu akan menjadi salah satunya :).

— Mike Strobel

2

Banyak bahasa di luar C / C ++ memberikan batasan pada file. Ricket menyebutkan Java 'satu kelas per file'; Python menggunakan file sebagai ruang nama; bahasa lain sering meniru semangat mereka.

Jika Anda menggunakan C atau C ++, lebih banyak file yang disertakan umumnya berarti waktu kompilasi yang lebih lama per file; di sisi lain, lebih sedikit berarti lebih banyak untuk dikompilasi ulang saat melakukan perubahan kecil. Karena enumerasi tidak dapat dideklarasikan maju dalam C, Anda harus selalu memasukkannya ke dalam file header yang hanya berisi enum lain, untuk kewarasan ketergantungan.

Kalau tidak, "satu file per kelas" Java adalah wajar, tetapi untuk waktu yang lama Java telah mendukung kelas dalam - seperti wadah, dan kelas dalam iteratornya. Demikian pula dalam bahasa lain, Anda mungkin menginginkan satu catatan / struct / class / type / interface / blorb per header yang dominan, tetapi dapat memutuskan untuk menyertakan pembantu atau wadah terkait juga.

(Anda tidak perlu menggunakan model komponen, tetapi jika Anda memiliki hierarki kelas yang dalam dan spesifik seperti itu, Anda akan membenci diri sendiri nanti.)

Saya menggunakan hierarki sebagai contoh; Saya merasa itu memang menekankan apa yang saya maksud lebih baik. Dalam kode aktual, saya berjuang menuju komponen.

— The Communist Duck