2009-03-02 40 views
19

Về dự án, chúng tôi đang cố gắng đạt được thỏa thuận về việc sử dụng không gian tên. Chúng tôi đã quyết định rằng cấp đầu tiên sẽ là "productName" và thứ hai là "moduleName".Sử dụng không gian tên và quy tắc đặt tên C++

productName::moduleName 

Bây giờ nếu mô-đun là loại mô-đun tiện ích, không có vấn đề gì để thêm không gian tên thứ ba. Ví dụ để thêm "str": productName :: utilityModuleName :: str - để chia không gian nơi tất cả các "chuỗi" liên quan đến công cụ sẽ đi.

Nếu mô-đun là mô-đun kinh doanh chính, chúng tôi có nhiều cơ hội và hầu như không có thỏa thuận.

Ví dụ

class productName::mainModuleName::DomainObject 

class productName::mainModuleName::DomainObjectSomethingElseViewForExample 

có thể cả ở

namespace productName::mainModuleName::domainObject 
class Data 
class ViewForExample 

Tại sao chúng ta nên tạo ra các lớp bên trong không tư nhân và không gian tên? Tại sao chúng ta nên tạo lớp mà tất cả các phương thức là tĩnh (trừ trường hợp khi lớp này sẽ là tham số mẫu)?

Dự án bao gồm 1Gb mã nguồn. Vì vậy, cách tốt nhất để phân chia các mô-đun trên các không gian tên trong C++ là gì?

+7

1 Gb mã nguồn? : o Đó là một dự án thực sự rất lớn! –

Trả lời

32

gì namespace là dành cho:

Namespaces có nghĩa là để thiết lập ngữ cảnh chỉ vì vậy bạn không cần phải confilcts đặt tên.

Quy tắc chung:

Xác định quá nhiều bối cảnh không cần thiết và sẽ gây ra sự bất tiện hơn nó là giá trị.

Vì vậy, bạn muốn sử dụng phán đoán tốt nhất của bạn, nhưng vẫn làm theo các quy tắc 2:

  • Đừng quá chung chung khi sử dụng không gian tên
  • Đừng quá cụ thể khi sử dụng không gian tên

Tôi sẽ không nghiêm khắc về cách sử dụng tên không gian tên và chỉ cần sử dụng các không gian tên dựa trên một nhóm mã liên quan.

Tại sao không gian tên quá chung chung là không hữu ích:

Vấn đề với cách chia không gian tên bắt đầu với tên sản phẩm, là bạn sẽ thường có một thành phần của mã, hoặc một số thư viện cơ sở đó là phổ biến cho nhiều sản phẩm.

Bạn cũng sẽ không sử dụng không gian tên Product2 bên trong Product1, vì vậy hãy chỉ định rõ ràng nó là vô nghĩa. Nếu bạn đã bao gồm các tệp của Product2 bên trong Product1, thì chuyển đổi đặt tên này có hữu ích không?

Tại sao không gian tên đó quá cụ thể không hữu ích:

Khi bạn có không gian tên đó quá cụ thể, ranh giới giữa các không gian tên khác nhau bắt đầu mờ. Bạn bắt đầu sử dụng các không gian tên bên trong lẫn nhau. Tại thời điểm này, tốt hơn là khái quát chung mã chung với nhau trong cùng một không gian tên.

Lớp học với tất cả các tĩnh vs mẫu:

"? Tại sao chúng ta nên tạo ra bên trong không lớp tư nhân và không gian tên Tại sao chúng ta nên khai báo class nơi mà tất cả phương pháp tĩnh"

Một số khác biệt:

  • Namespaces có thể được ngụ ý bằng cách sử dụng các từ khóa using
  • Namespaces có thể aliased, các lớp học nhiều loại và có thể được typedef'ed
  • Namespaces có thể được thêm vào; bạn có thể thêm chức năng cho nó bất cứ lúc nào và thêm vào nó trực tiếp
  • Lớp học không thể được thêm vào mà không cần thực hiện một lớp được thừa kế mới
  • Namespaces có thể có tờ khai phía trước
  • Với các lớp, bạn có thể có các thành viên tư nhân và các thành viên bảo vệ
  • Lớp học có thể được sử dụng với các mẫu

chính xác làm thế nào để phân chia:

"Dự án bao gồm 1Gb mã nguồn . Vì vậy, việc thực hành tốt nhất để module chia trên không gian tên trong c là gì ++?"

Đó là quá chủ quan để nói chính xác làm thế nào để phân chia mã của bạn mà không cần mã nguồn chính xác. Chia dựa trên các module mặc dù âm thanh logic , không phải toàn bộ sản phẩm

+0

Ok, nếu tôi sẽ thêm sau đó domainObject :: Cài đặt và anh chàng khác sẽ thêm DomainObjectValidator và như vậy - sẽ có một dấu gạch ngang. –

+0

Tại sao bạn sẽ bao gồm một số sản phẩm khác bao gồm các tệp vào sản phẩm của bạn? –

+0

Thực tế là bạn có thể gặp phải vấn đề này có nghĩa là bạn không nên đánh dấu chúng bằng tên sản phẩm, vì điều đó có nghĩa là bạn đang sử dụng mô-đun này trong một sản phẩm mà không gian tên của nó không phù hợp. –

3

Đây là tất cả chủ quan, nhưng tôi sẽ ngần ngại đi sâu hơn 3 cấp độ. Nó chỉ là quá khó sử dụng tại một số điểm. Vì vậy, trừ khi cơ sở mã của bạn là rất, rất lớn, tôi sẽ giữ cho nó khá nông.

Chúng tôi chia mã của chúng tôi thành các hệ thống con và có một vùng tên cho mỗi hệ thống con. Những thứ tiện ích sẽ đi vào không gian tên của chúng nếu thực sự chúng có thể tái sử dụng trên các hệ thống con.

+0

Vì vậy, không có "Miền Miền" khác nhau? Tôi có nghĩa là tất cả các lớp học kinh doanh trong cùng một không gian tên? –

+0

Thật khó để hiểu ý bạn là gì nếu không nhìn thấy kiến ​​trúc của bạn, nhưng một không gian tên cho mỗi Vùng miền giống như một ý tưởng hay đối với tôi. Toàn bộ ý tưởng là để ngăn chặn xung đột tên khi trộn các vùng khác nhau của mã. –

4

Dường như với tôi rằng bạn đang cố gắng sử dụng các không gian tên như một công cụ thiết kế, chúng không nhằm mục đích, chúng được thiết kế để ngăn chặn xung đột tên. , bạn không cần các không gian tên.

+6

Vậy sao? tại sao sau đó tăng cường giới thiệu rất nhiều cấp độ khác nhau? Nó chỉ có thể sử dụng tên dài. như boostThreadJoinAll. Không gian tên là công cụ để duyệt web. Loại hiển thị cho tôi tất cả liên quan đến Miền. –

+2

Boost sử dụng chúng để ngăn chặn xung đột tên, như tôi đã nói. –

0

tôi chia không gian tên tùy thuộc vào tập quán của nó:

Tôi có một không gian tên riêng biệt, nơi tôi đã xác định tất cả các giao diện của tôi (lớp ảo thuần túy).

Tôi có một không gian tên riêng biệt, nơi tôi đã xác định các lớp thư viện của mình (như thư viện db, thư viện xử lý).

Và tôi có một không gian tên riêng biệt, nơi tôi có các đối tượng kinh doanh cốt lõi (logic nghiệp vụ) của tôi (như purchase_order, v.v.).

Tôi đoán, về việc xác định nó theo cách nào đó, điều đó sẽ không khó xử lý trong tương lai. Vì vậy, bạn có thể kiểm tra những khó khăn sẽ bao quanh trên thiết kế hiện tại của bạn.

Và nếu bạn nghĩ chúng ổn, bạn nên đi với nó.

Các vấn đề liên quan