Đặt tên giao diện: tiền tố 'Can-' vs hậu tố '-Able'

Người ta thường sử dụng '-able' làm hậu tố cho các giao diện, vd

Có thể in nối tiếp có thể in được

Tôi đã nghĩ rằng 'Can-' có thể tốt hơn bởi vì nó có thể mô tả nhiều hơn. Vâng, nó dài dòng hơn và nó thêm tiếng ồn cho tên giao diện. Đặc biệt, động từ thụ động có thể được sử dụng.

Ví dụ 1 không Shootable có nghĩa là đối tượng có thể bắn (một khẩu súng có thể thực hiện điều này) hoặc có nghĩa là nó có thể bị bắn vào (một bảng mục tiêu có thể thực hiện điều này). Với tiền tố 'Can-', cái trước sẽ là "CanShoot" và cái sau sẽ là "CanBeShotAt" hoặc "CanShootAt".

Ví dụ: 2 Tài liệu 'CanBePrinted' và máy in 'CanPrint'

Hoặc, chúng ta có nên gắn bó với '-Able' và để tài liệu cung cấp bối cảnh không?

Mọi ý kiến.

Có lẽ bạn muốn có khả năng?

Một số ví dụ từ .Net:

NetworkStream.Readable
NetworkStream.Writable
Stream.CanRead
Stream.CanWrite
Type.IsSerializable

Dường như không có một tiêu chuẩn thống nhất. Đi với những gì đọc tốt.

if (document.IsPrintable && printer.CanPrint) { printer.Print(document) }

EDIT: Như đã chỉ ra, câu hỏi là về Giao diện, không phải thuộc tính.

Trong trường hợp đó, tôi không thể tìm thấy bất kỳ giao diện nào có tên Can-. Các giao diện có xu hướng luôn luôn có thể sử dụng. Tôi đồng ý với thuật ngữ này. Một phương thức có thể yêu cầu như một tham số a ISerializable objecthoặc IPrintable document. Yêu cầu một ICanBeSerialized objecthoặc ICanBePrinted documentrất khó đọc.

Mặt khác, Máy in, tôi đề nghị chỉ cần gọi giao diện IPrinter. Phương pháp của bạn sẽ được yêu cầu a IPrinter device.

Đọc chữ ký phương thức dưới đây thành tiếng. (Cá nhân, tôi coi tiền tố "Tôi" là im lặng.) Nó có đọc tốt không? Nghe có vẻ đúng không?

void PrintDocument(IPrinter device, IPrintable document)
{
    device.Print(document)
}

Nói theo ngữ pháp, "canFoobar" là một vị ngữ, trong khi "Foobarable" là tính từ hoặc danh từ (thường là danh từ trong ngữ cảnh của API).

Cũng lưu ý sự khác biệt tinh tế: -able ngụ ý một vai trò thụ động cho danh từ mà nó được áp dụng, nghĩa là, nếu Something là Foobarable, thì nó có thể bị foobared bởi một thứ khác; có thể ngụ ý một vai trò tích cực, nghĩa là, nếu Something canFoobar, thì nó có thể foobar một cái gì đó khác. Hoặc, từ một góc độ khác: nếu A có thể foobar B, thì A.canFoobar()và B is Foobarable.

Về mặt biểu cảm OOP, tôi liên kết các vị từ với các phương thức hoặc thuộc tính, trong khi danh từ là các lớp hoặc giao diện. Vì thế:

instance.canFoobar();

class Something implements Foobarable { ... }

Cá nhân tôi sẽ gắn bó với phiên bản -able. Đây là lý do của tôi: Hầu hết (tất cả?) Các biên tập viên đồ họa đề xuất các định danh dựa trên những gì bạn đã nhập. Mặc dù một số trong số chúng đủ 'thông minh' để tìm kiếm trong các định danh, một số vẫn chỉ cung cấp các bắt đầu tìm kiếm của các định danh.

Để tăng tốc độ nhập, bạn muốn rút ngắn danh sách các số nhận dạng được đề xuất với càng ít lần nhấn phím càng tốt. Càng nhiều số nhận dạng có cùng một khởi đầu, ví dụ 'ICan-' bạn sẽ phải nhập nhiều ký tự hơn.

Nếu bạn nghĩ rằng đây không phải là vấn đề trong trường hợp của bạn thì điều đó thật tuyệt và tôi khuyên bạn nên sử dụng các tiêu chí khác để chọn quy ước đặt tên. Trong một số trường hợp, ví dụ như trong nhóm của chúng tôi, chúng tôi thích các số nhận dạng phân biệt sau càng ít lần nhấn phím càng tốt.

Ngoài ra, tôi khuyên bạn nên sử dụng quy ước đặt tên làm cho mã của bạn dễ hiểu nhất đối với những người làm việc trong dự án. Có một cuộc trò chuyện trong nhóm của bạn. Không có đúng hay sai như vậy. Chỉ cần những quy ước làm việc và những quy ước mà làm việc ít hơn.

Đừng quên rằng các công cụ tái cấu trúc tốt cho phép bạn đổi tên mọi thứ bao nhiêu lần tùy thích. Vì vậy, thật dễ dàng để thử nghiệm các phương pháp khác nhau.

Rõ ràng tiền tố và hậu tố là những lựa chọn gần như rõ ràng cho các loại hành động khác nhau hay đúng hơn là các hướng khác nhau của một hành động.

Việc sử dụng và sở thích hiện tại có thể không nhất quán do nhiều lý do.

Hành động được thực hiện bởi đối tượng:
CanShoot -> Nó bắn (at) một cái gì đó
CanFly -> Nó bay
CanChange -> Nó thay đổi

Hành động được thực hiện trên đối tượng: Có thể đọc
-> Bạn có thể đọc nó
Có thể ghi -> Bạn có thể viết (vào) nó Có
thể in -> Bạn có thể in nó

Mặc dù nó có thể không phải là một quy tắc hoặc thậm chí nhất thiết phải hợp lý, nhưng nó giúp thông qua quy ước và duy trì tính nhất quán của việc sử dụng trong việc đặt tên biến.

Tôi nghĩ bạn có thể muốn phân biệt giữa khả năng và sự cho phép. Mặc dù Serializablevà CanSerializengụ ý rằng một cái gì đó có khả năng được tuần tự hóa, cũng có những vấn đề về quyền (hoặc có thể thiếu không gian đĩa) và bạn có thể cần phải xem xét MaySerialize. Để lại những thứ tại ~ableloại bỏ sự cần thiết phải phân biệt giữa canvà may.

Khi phân lớp / thực hiện giao diện, tôi nghĩ rằng quy tắc chung là bạn sẽ có thể nói "B là A" (trong đó B thực hiện A). Nghe có vẻ không đúng:

A Documentlà mộtCanBePrinted

Nhưng nghe có vẻ đúng (hoặc ít nhất là tốt hơn) để nói:

A Documentlà mộtPrintable

Tôi nghĩ rằng cả Xable thông minh về ngữ pháp và thông thường đều tốt hơn cho tên của các giao diện, trong khi IsX, CanX, DoesX tốt hơn cho tên của các thuộc tính.

Từ MSDN:

"Đặt tên các thuộc tính Boolean bằng cụm từ khẳng định (CanSeek thay vì CantSeek). Tùy chọn, bạn cũng có thể đặt tiền tố các thuộc tính Boolean bằng Is, Can hoặc Has, nhưng chỉ khi nó tăng giá trị." http://msdn.microsoft.com/en-us/l Library / ms229012.aspx

Theo ý kiến ​​của tôi, biến thể "có thể" dễ đọc hơn nhiều so với "CanDoSthing" được đề xuất của bạn, trong đó áp đặt bướu lạc đà nhiều hơn.

Trong Scala, *Ableđược sử dụng cho các giao diện, nhưng Can*được sử dụng cho mẫu lớp loại. Về cơ bản, để có thể gọi một số phương thức nhất định, một giá trị ngầm định của một loại nhất định phải tồn tại trong phạm vi. Tên của loại này đôi khi có tiền tố Can.