Tên gói nên là số ít hoặc số nhiều?

227

Thông thường, trong các thư viện đặc biệt, các gói chứa các lớp được tổ chức xung quanh một khái niệm duy nhất. Ví dụ: xml, sql, người dùng, cấu hình, db . Tôi nghĩ rằng tất cả chúng ta đều cảm thấy khá tự nhiên rằng các gói này là chính xác trong số ít .

com.myproject. xml .Element
com.myproject. sql
. Kết nối com.myproject. người dùng . Người dùng
com.myproject. người dùng .UserFactory

Tuy nhiên, nếu tôi có một gói thực sự chứa một tập hợp các triển khai của một loại duy nhất - chẳng hạn như các tác vụ, quy tắc, trình xử lý, mô hình, v.v. , thì thích hợp hơn?

com.myproject. nhiệm vụ .TakeOutGarbageTask
com.myproject. nhiệm vụ .DoTheDishesTask
com.myproject. nhiệm vụ .PaintTheHouseTask

hoặc là

com.myproject. tác vụ .TakeOutGarbageTask
com.myproject. nhiệm vụ .DoTheDishesTask
com.myproject. nhiệm vụ .PaintTheHouseTask

object-oriented naming packages

— Nicole
nguồn

số ít giống như tên bảng cơ sở dữ liệu phải luôn là số ít nhưng vì những lý do khác nhau. Nhìn vào bất kỳ thư viện tiêu chuẩn phổ biến như Java hoặc Python chẳng hạn.

@Jarrod Roberson: Vui lòng gửi câu trả lời của bạn dưới dạng câu trả lời để chúng tôi có thể nâng cao câu trả lời đúng.

— S.Lott

@Jarrod sẽ cần một số ví dụ, vì trong các thư viện tiêu chuẩn, hầu hết các lớp đều thuộc danh mục đầu tiên tôi liệt kê.

— Nicole

@Renesis Hãy xem câu trả lời cập nhật của tôi.

— Matthew Rodatus

@Matthew - Tôi thích nó. Bạn đã bày tỏ những gì tôi nghi ngờ nhưng không chắc chắn làm thế nào để mã hóa.

— Nicole

Câu trả lời:

293

Sử dụng số nhiều cho các gói có nội dung đồng nhất và số ít cho các gói có nội dung không đồng nhất.

Một lớp tương tự như một mối quan hệ cơ sở dữ liệu. Một quan hệ cơ sở dữ liệu nên được đặt tên theo số ít vì các bản ghi của nó được coi là các thể hiện của mối quan hệ. Chức năng của một mối quan hệ là tạo một bản ghi phức tạp từ dữ liệu đơn giản.

Mặt khác, một gói không phải là một sự trừu tượng hóa dữ liệu. Nó hỗ trợ với tổ chức mã và giải quyết xung đột đặt tên. Nếu một gói được đặt tên theo số ít, điều đó không có nghĩa là mỗi thành viên của gói là một thể hiện của gói; nó chứa các khái niệm liên quan nhưng không đồng nhất. Nếu nó được đặt tên ở số nhiều (như thường thấy ), tôi sẽ mong đợi rằng gói chứa các khái niệm đồng nhất.

Ví dụ, một loại nên được đặt tên TaskCollectionthay vì TasksCollection, vì nó là một bộ sưu tập có chứa các thể hiện của a Task. Một gói có tên com.myproject.taskkhông có nghĩa là mỗi lớp chứa là một thể hiện của một tác vụ. Có thể có một TaskHandler, một TaskFactory, vv Một gói có tên com.myproject.tasks, tuy nhiên, sẽ chứa các loại khác nhau mà là tất cả các nhiệm vụ: TakeOutGarbageTask, DoTheDishesTaskvv

— Matthew Rodatus
nguồn

Đối với một câu hỏi tương tự, xem English.stackexchange.com/q/25713 . Một thể loại tương tự với số ít và một loại tương tự với số nhiều.

— Matthew Rodatus

Chính liên kết bạn cung cấp cho thấy một ngoại lệ cho quy tắc này. beanslà số nhiều, tuy nhiên java.beanschứa tất cả các loại lớp liên quan đến JavaBeans.

— SkyDan

Câu trả lời tốt, nhưng tôi không đồng ý với logic quan hệ cơ sở dữ liệu. Mối quan hệ trong ERD là số ít vì chúng hiển thị mối quan hệ giữa các thực thể. Các bảng là một triển khai vật lý của các mối quan hệ và chúng giữ nhiều hàng và do đó nên là IMO số nhiều. Câu trả lời cho "cái gì trong bảng này?" là "người dùng" chứ không phải "người dùng". Cấp, có vẻ như việc đặt tên số ít phổ biến hơn trong thế giới doanh nghiệp (C #, Java) so với các cộng đồng như Ruby, Python, Javascript và PHP.

— ryeguy

Nhận xét của @ SkyDan chỉ ra một điều rất quan trọng đang bị bỏ qua hoàn toàn ở đây. Tôi nhận thấy rằng việc đặt tên số nhiều của "java.beans" thực sự là một sai lầm và thay vào đó nó nên được đặt tên là "java.bean", số ít.

— Vicky Chijwani

@VickyChijwani @SkyDan vì JavaBeans ™ là nhãn hiệu, có lẽ họ muốn giữ tên như là để chỉ chính công nghệ và do đó họ đã sử dụng java.beans.

— Hejazi

Điều này có lẽ phụ thuộc vào một ngôn ngữ cụ thể. Trong .NET (C #), nó chắc chắn phải là số nhiều nếu có khả năng xảy ra xung đột tên kiểu không gian tên ( type name expected but namespace foundlỗi). Tôi đã xử lý vấn đề này, nó không dễ chịu và dẫn đến các tên loại đủ điều kiện trên tất cả các mã. Ví dụ .

— Den
nguồn