Chia thành các tập tin - chia bao nhiêu?

9

Nếu tôi nói tôi có một khung thực thể phân cấp, chứ không phải là một mô hình thành phần. Một cái gì đó như:
(Vâng, cái này được tạo thành)

Weapon-> Gun-> AutomaticGun-> MP44
Hoặc, nhiều hơn một ví dụ cổ điển:
Entity-> MovableEntity-> Enemy-> WalkingEnemy

Bạn sẽ chia các tệp nguồn / tiêu đề bao xa để dễ đọc và tổ chức? Là cách tốt nhất để đi một cái gì đó như Entity.cpp, MovableEntity.cpp, Enemy.cpp, v.v. hoặc một cách tiếp cận như Entity.cpp [chứa Entity và MovableEntity] và Enemy.cpp [chứa Enemy và WalkingEnemy] sẽ tốt hơn? (Hoặc theo cách không thể biết bằng ngôn ngữ hơn, tệp Enemy và tệp Thực thể so với tệp cho mỗi lớp?)
Ngoài ra, điều này có ảnh hưởng đến bất cứ điều gì ngoài khả năng đọc và tổ chức không?

c++ file

— Vịt Cộng sản
nguồn

1

Nitpicky, nhưng tôi không nghĩ language-agnosticlà một thẻ thích hợp vì nó phụ thuộc rất lớn vào ngôn ngữ bạn đang sử dụng như các tác dụng phụ.

— Tetrad

Điểm tốt, tôi nghĩ rằng tôi có thể thử lại.

— Vịt Cộng sản

12

Đây hoàn toàn là một vấn đề ưu tiên. Tuy nhiên, cá nhân tôi tin rằng tốt nhất là sai ở phía nhiều tệp hơn. Ví dụ, Java yêu cầu một lớp cho mỗi tệp , với tên tệp giống như tên lớp; họ thực hiện điều này bằng chính sách để thực thi thực hành tốt này (mặc dù bạn có thể có các lớp con về cơ bản xoay quanh vấn đề này).

Ngoài ra, các hệ thống kiểm soát nguồn khá tốt trong việc hợp nhất các thay đổi trong một tệp, nhưng sẽ ít rắc rối hơn nếu bạn chỉ làm việc trong các tệp hoàn toàn riêng biệt. Bạn cũng có thể dễ dàng xem ai đã thay đổi lớp nào. Giả sử một nhà phát triển khác thực hiện thay đổi tệp AllEntities.h; bạn không biết chính xác thực thể (hoặc thực thể) nào mà anh ấy đã thay đổi cho đến khi bạn mở tệp và nhìn vào đầu ra khác.

Tuy nhiên, thật tuyệt khi nhóm các cấu trúc nhỏ và enum liên quan đến lớp trong tệp của một lớp . Nếu bạn có một enum chỉ được sử dụng bởi một lớp duy nhất, tại sao lại chia nó thành tệp riêng của nó? Chỉ cần đặt chúng lại với nhau. Nhưng nếu nó được sử dụng bởi một lớp khác (tức là một thành viên khác thuộc loại enum này), thì đó là lúc để cung cấp cho nó tệp riêng của nó.

— Dế
nguồn

Đã đồng ý. Sự phức tạp của các loại của bạn chắc chắn phải là một yếu tố. Nếu ngôn ngữ của bạn hỗ trợ các lớp một phần (hoặc nếu việc triển khai thành viên có thể được tổ chức tương tự như C ++), thì tôi thậm chí sẽ khuyên bạn nên chia các loại đặc biệt phức tạp thành nhiều tệp. Ví dụ: nếu có một giao diện (lớn) mà lớp của bạn phải triển khai, nhưng mã này khá chung chung và không liên quan lắm đến phần còn lại, bạn có thể chia mã đó thành một tệp / lớp riêng biệt. Đối với các loại enum, tôi nghĩ rằng bạn có thể thoát khỏi việc đặt tất cả các enum cho một không gian tên nhất định trong một tệp.

— Mike Strobel

1

Không nhóm các enum của bạn có nghĩa là thay đổi một giá trị sẽ gây ra việc biên dịch lại mọi tệp sử dụng một enum trong không gian tên đó?

— Vịt Cộng sản

Chà, điều đó thực sự phụ thuộc vào ngôn ngữ, nhưng vâng, nó chắc chắn có thể có tác dụng đó. Nó thực sự không phải là vấn đề đối với tôi, vì tôi phát triển chủ yếu bằng C # (không biên dịch từng tệp), nhưng nó có thể có vấn đề trong C ++ và các ngôn ngữ khác. Như mọi khi, có những yếu tố ngôn ngữ cụ thể để xem xét, và đó sẽ là một trong số đó :).

— Mike Strobel

2

Nhiều ngôn ngữ bên ngoài C / C ++ áp đặt các ràng buộc đối với các tệp. Ricket đã đề cập đến 'một lớp trên mỗi tệp' của Java; Python sử dụng các tệp làm không gian tên; các ngôn ngữ khác thường sao chép tinh thần của những người đó.

Nếu bạn đang sử dụng C hoặc C ++, các tệp được bao gồm nhiều hơn thường có nghĩa là thời gian biên dịch dài hơn cho mỗi tệp; mặt khác, ít có nghĩa là phải biên dịch lại nhiều hơn khi thực hiện các thay đổi nhỏ. Vì các liệt kê không thể được khai báo chuyển tiếp trong C, bạn nên luôn đặt chúng vào các tệp tiêu đề chỉ chứa các enum khác, cho sự tỉnh táo phụ thuộc.

Mặt khác, "một tệp cho mỗi lớp" của Java là hợp lý, nhưng trong một thời gian dài Java đã hỗ trợ các lớp bên trong - như một thùng chứa và một lớp bên trong của trình vòng lặp của nó. Tương tự như vậy trong bất kỳ ngôn ngữ nào khác, bạn có thể sẽ muốn một bản ghi / struct / class / type / interface / blorb chiếm ưu thế trên mỗi tiêu đề, nhưng cũng có thể quyết định bao gồm các trình trợ giúp hoặc bộ chứa liên quan.

(Bạn không cần sử dụng mô hình thành phần, nhưng nếu bạn có hệ thống phân cấp lớp sâu và cụ thể như thế, bạn sẽ ghét chính mình sau này.)

Tôi đã sử dụng hệ thống phân cấp làm ví dụ; Tôi cảm thấy nó đã nhấn mạnh những gì tôi có nghĩa là tốt hơn. Trong mã thực tế, tôi đang phấn đấu hướng tới các thành phần.

— Vịt Cộng sản