接口和抽象類的描述性命名約定

我最近一直以更具描述性的方式嘗試命名抽象類和接口。主要是試圖確保它們不偏離其預期目的。接口和抽象類的描述性命名約定

所以對於抽象類我一直用ISA或ISAN接口的ICAN或IPerform

例如，代替IOperationManager; ICanPerformOperationManagement

我發現這看起來更好看課堂。

我敢肯定，我不是第一個這樣想，如果有人已經使用接口和抽象類任何一種描述性的命名約定不知道？它會擴展到大型項目，還是隻是增加了混亂？

編輯：這個問題太主觀了嗎？

來源

2012-01-23 Dve

我傾向於嘗試將接口命名爲對象* IS *的描述，並且在您的示例中將使用「IOperationManager」。 – asawyer

也許更適合程序員。 – Nix

「這個問題太主觀了嗎？「如果你不得不問......它可能是，我認爲這也不適合程序員，雖然。 – BoltClock

對於我來說，就是要採取短期和描述，消除了多餘的名稱術語。

個人不認爲有必要包括Can或接口名稱Perform，因爲非常實用擺在首位接口的描述 - 的屬性和方法，然後描述什麼它應該能夠做到。想一想這種方式 - 你會有ICantPerform...爲不類型實現接口？當然不是;界面要麼被執行，要麼不在那裏。

如果開發人員理解接口是什麼，那麼他們就明白這一點。如果他們不這樣做;他們不應該使用接口，直到他們做。

這與抽象類型相同。 IsA或IsAn又是多餘的，因爲只要類型從它繼承，關係就完成了。正如安德魯博士說的那樣（+ 1） - Base後綴是有用的，因爲它暗示着那裏有抽象的行爲要實現（這與BCL的其他部分很好地匹配）。

對我而言，IOperationManager是有意義的; ICanPerformOperationManagement笨重。

來源

2012-01-23 13:18:25

+1就在你身後 –

Abtract類我傾向於追加基地給它，例如ViewModelBase或NodeBase。

對於接口，I傾向於描述對象，所以IOperationManager而非ICanPerformOperationManagement。話雖如此，我偶爾會將界面從無聊的IDrawable更名爲更有趣的ICanBeDrawn

請考慮開發者如何使用代碼庫。如果您正在學習intellisense，並且知道您有一個名爲OperationManager的課程，則您會希望其接口爲IOperationManager。很少人會在第一次嘗試猜測，他們應該開始鍵入I..C..a..n..P..e..等等

來源

2012-01-23 13:18:04

我也傾向於使用BaseViewModel/ViewModelBase，但問題是如果我需要添加另一個類是在那個之上？它會是ViewModelBaseBase還是ActualViewModelBase？所以我只是離開基地並將其稱爲ViewModel。如果我需要知道某種類型是否抽象，在任何IDE中都很容易 –

@ ToniParviainen在命名課程時需要一小撮鹽，也就是「一些明智」，這樣做就足夠了，你變成了一隻手，然後你發現你的團隊中有其他人不同意。醇。就個人而言，我會'ViewModelBase'，但然後說派生（但仍然是抽象類型）爲'SomeSpecificFunctionalityButStillAbstractViewModel'。所有vms必須從'ViewModelBase'繼承，但不是全部來自'SomeSpecificFunctionalityButStillAbstractViewModel'。雖然沒有正確的方法。總之，只要做些什麼 –

接口和抽象類的描述性命名約定

回答

相關問題