IPretend that the 'I' prefix in interface names acts as an indicator of the action or capability encapsulated by the interface. By adhering to this idea, we anthropomorphize our interfaces, making it easier to understand their roles.
Some examples:
ILog
IWriteToDatabase
IReadFromDatabase
IAuthenticateUsers
IPostComments
No, in my opinion it's bad just the same. I use adjectives derived from the names of the required methods. The interface tells the class what capabilities it must have. Contract tells word contract only, no ability.
Indeed. It's an odd dissimilarity between C# and Java, that in Java it's the interfaces that are typically/often seen as primary: you have a Car interface and a CarImpl class (or rather, a specific type of car). After that, the user of the Car instance should only care about the instance being a Car, not which specific kind of car, apart from what can be gleaned via the interface's methods.
Hungarian notation is still alive:
class Logger implements ILogger
I hate the prefix "I".
i feel you
How would you name your interfaces for dependency injection?
It depends on what abilities will be required from the injected object.
ILogger
is not an ability.IPretend that the 'I' prefix in interface names acts as an indicator of the action or capability encapsulated by the interface. By adhering to this idea, we anthropomorphize our interfaces, making it easier to understand their roles.
Some examples:
ILog
IWriteToDatabase
IReadFromDatabase
IAuthenticateUsers
IPostComments
For anthropomorphize our interfaces use adjectives:
Have you tried the contract naming? Instead of
I
it would beLoggerContract
.No, in my opinion it's bad just the same. I use adjectives derived from the names of the required methods. The interface tells the class what capabilities it must have. Contract tells word contract only, no ability.
Indeed. It's an odd dissimilarity between C# and Java, that in Java it's the interfaces that are typically/often seen as primary: you have a Car interface and a CarImpl class (or rather, a specific type of car). After that, the user of the Car instance should only care about the instance being a Car, not which specific kind of car, apart from what can be gleaned via the interface's methods.
Interface first, implementation last.