Quy ước đặt tên cho các lớp trừu tượng

Tôi nhớ rõ rằng, tại một thời điểm, hướng dẫn do Microsoft thúc đẩy là thêm hậu tố "Base" vào một lớp trừu tượng để xóa bỏ thực tế rằng nó là trừu tượng. Do đó, chúng tôi có các lớp học như System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBase, và, tất nhiên, System.Collections.CollectionBase.

Nhưng tôi nhận thấy rằng, rất nhiều lớp trừu tượng trong Framework dường như không tuân theo quy ước này. Ví dụ: tất cả các lớp sau đây đều là trừu tượng nhưng không tuân theo quy ước này:

• System.DirectoryServices.ActiveDirectory.DirectoryServer

• System.Configuration.ConfigurationElement

• System.Drawing.Brush

• System.Windows.Forms.CommonDialog

Và đó chỉ là những gì tôi có thể đánh trống lảng trong vài giây. Vì vậy, tôi đã tìm kiếm tài liệu chính thức nói gì, để đảm bảo rằng tôi không bị điên. Tôi đã tìm thấy Tên của Lớp, Cấu trúc và Giao diện trên MSDN tại Hướng dẫn Thiết kế để Phát triển Thư viện Lớp . Thật kỳ lạ, tôi không thể tìm thấy đề cập nào về hướng dẫn thêm "Cơ sở" vào cuối tên của lớp trừu tượng. Và các hướng dẫn không còn có sẵn cho phiên bản 1.1 của Framework.

Vì vậy, tôi mất nó? Hướng dẫn này đã bao giờ tồn tại? Nó chỉ bị bỏ rơi mà không có một lời nói? Tôi đã tự mình tạo ra các tên lớp dài trong hai năm qua mà không có gì?

Ai đó ném cho tôi một khúc xương ở đây.

Cập nhật Tôi không điên. Hướng dẫn đã tồn tại. Krzysztof Cwalina nghiền ngẫm về nó vào năm 2005.

Trong Hướng dẫn Thiết kế Khung trang 174 nêu rõ:

Tránh đặt tên các lớp cơ sở với hậu tố "Cơ sở" nếu lớp được thiết kế để sử dụng trong các API công khai.

Ngoài ra: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx

Ngoài ra, nếu lớp trừu tượng có một vài thành viên tĩnh sẽ được sử dụng, thì 'Cơ sở' có thể trở nên xấu xí.

Tôi không nhớ một hướng dẫn như vậy. Tôi tin rằng bạn nên sử dụng cách đặt tên có ý nghĩa. Đôi khi lớp trừu tượng chỉ được thiết kế để cung cấp chức năng chung cho một số lớp (như một công cụ), mà tôi nghĩ nên có hậu tố. Tuy nhiên, trong một số trường hợp, bạn muốn sử dụng nó làm cơ sở của hệ thống phân cấp đa hình mà bản thân nó không hoàn chỉnh. Trong những trường hợp đó, tôi đề nghị đặt tên như một lớp bình thường.

Như bạn thấy, bạn có thể sẽ không khai báo một phương thức chấp nhận một tham số ButtonBase. Nó được thiết kế để cung cấp chức năng tối thiểu cho các lớp con. Tuy nhiên, bạn có thể coi một ConfigurationElementthực thể như một thực thể có các dạng khác nhau nhưng bản thân nó không hoàn chỉnh (và do đó nó trừu tượng)

Đôi khi Base vẫn cần thiết, đặc biệt là khi bạn cung cấp cả một lớp cụ thể và một lớp trừu tượng để ai đó có thể mở rộng để tạo ra một triển khai cụ thể.
ví dụ: Controller và ControllerBase (thực ra Controller cũng trừu tượng, nhưng cung cấp nhiều chức năng hơn đáng kể so với ControllerBase)

Hậu tố cơ sở là xấu khi lập trình với một giao diện, vì vậy tôi nghĩ hướng dẫn của Microsoft không sử dụng nó được áp dụng khi lớp trừu tượng được sử dụng chủ yếu như một giao diện. Có lẽ chúng có nghĩa là API công khai.

Vấn đề là có những trường hợp không có giải pháp thay thế nào tốt hơn là sử dụng hậu tố Cơ sở.

Tôi hiểu khuynh hướng tránh dùng Hậu tố cơ sở, nhưng tôi cũng hiểu sự cần thiết của một số Hậu tố. Bây giờ, một Nhận xét của bài viết này đề xuất sử dụng "Loại" làm Hậu tố làm lựa chọn thứ hai để không sử dụng bất kỳ. Tôi tin rằng điều này là khó hiểu, nhưng ý tưởng rằng "một từ không cam kết như vậy sẽ có xu hướng chỉ ra rằng đó là một lớp không cam kết" bị mắc kẹt với tôi.

Thay thế: Tôi muốn sử dụng "Kind" làm hậu tố để nêu đối tượng là "thuộc hoặc thuộc chủng tộc hoặc gia đình cụ thể" ( Wiktionary: -kind ).

Ví dụ: DataProvidervà ReflectiveDataProviderđều làDataProviderKind

Lấy cảm hứng từ môn Sinh học, ví dụ như "canis lupus" thuộc họ "Canoidea", được dịch rất gần nghĩa là "dog-ish".

Microsoft tuyên bố, tại:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces

"✓ CONSIDER kết thúc tên của các lớp dẫn xuất bằng tên của lớp cơ sở. Điều này rất dễ đọc và giải thích mối quan hệ rõ ràng. Một số ví dụ về điều này trong mã là: ArgumentOutOfRangeException, là một loại Ngoại lệ và SerializableAttribute, là một loại Thuộc tính. Tuy nhiên, điều quan trọng là phải sử dụng phán đoán hợp lý khi áp dụng hướng dẫn này; ví dụ: lớp Nút là một loại sự kiện Điều khiển, mặc dù Điều khiển không xuất hiện trong tên của nó. "

Nói chung, điều này ngầm loại trừ việc sử dụng "Cơ sở" trong tên.