I have recently been experimenting with naming abstract classes and interfaces in a more descriptive way. Mainly to try and ensure that they do not stray from their intended purpose.
So for abstract classes I have been using IsA or IsAn for interfaces ICan or IPerform
For example, instead of IOperationManager; ICanPerformOperationManagement
I find this reads better when looking at class.
Im sure Im not the first to think like this and was wondering if anyone has used any sort descriptive naming convention for interfaces and abstract classes? Will it scale to large projects, or is it just adding confusion?
EDIT: Is this question too subjective!?
For me it’s about being short and descriptive, eliminating redundant terms in the name.
Personally don’t see the need to include
CanorPerformin an interface name, because the very use of an interface in the first place describes that – the properties and methods then describe what it should be able to do. Think about it this way – would you have anICantPerform...for types that don’t implement the interface? Of course not; the interface is either implemented or it’s not there to begin with.If the developer understands what an interface is, then they understand this. If they don’t; they shouldn’t be using interfaces until they do.
It’s the same with abstract types.
IsAorIsAnis again redundant, because as soon as a type inherits from it, the relationship is complete. As Dr.Andrew says (+1 there) – theBasesuffix is useful as it implies there is abstract behaviour there to be implemented (which fits nicely with the rest of the BCL too).For me,
IOperationManagermakes sense;ICanPerformOperationManagementis clunky.