Hi,
What is the standard in naming Interfaces and Implementation classes in Kotlin? In Java, I’ve seen the pattern someInterfaceName and someInterfaceNameImpl. In c# there is the IsomeClassName and someClassName pattern.
I’ve followed this link [https://kotlinlang.org/docs/reference/coding-conventions.html#naming-rules] but no description for interface naming is posted.
I haven’t seen any official word, but so far I think people have been doing roughly the same as for Java: using a noun or short noun phrase for the interface, and then using a prefix for each implementation describing how it’s implemented.
Obvious examples include the List interface, with implementations including ArrayList (implemented using an array), LinkedList (implemented using linked objects), and so on. Or Reader with FileReader and StringReader &c.
I’ve never seen the point in a fixed prefix or suffix, as the ‘[implementation][interface]’ form is more concise, readable, and useful. If you can’t think how to describe an implementation, consider how it would differ from any other possible implementation. (And if no other implementation is possible, then arguably the interface is redundant and should be dropped.)
Separate Interface and InterfaceImpl separations often make sense if you want to separate your API from your implementation, or if the other implementations exist solely for testing.
I personally despise the C# ISomeClassName pattern, because when I’m writing a class that uses existing code, I don’t really care whether I’m dealing with an interface or a class, they should be the same. The only exception is constructors, but then it’s already clear enough that I’m dealing with an implementation. The I prefixes just become noise whenever you write code that isn’t tied to implementations. I don’t mind the Impl suffix as much, because that should only come up near constructors or injection bindings.
Only if there’s at least the possibility of multiple implementations. And if so, then distinguish them! Even if one’s only for testing, you can call them TestXxx and ProdXxx , or TestXxx and MainXxx, or whatever. Don’t call one of them XxxImpl, because that name is meaningless — both of them are Xxx implementations!
Or if there can only ever be one, then what benefit would an interface give? It’s just pointless boilerplate — more code to read, maintain, and get out-of-date.
Not necessarialy. Especially for libraries or projects that expose parts of them as libraries, extracting implementation code into interfaces can be very useful, even if there will most likely ever be one implementation. This can be used to hide internal functions that you still need to be public. I think the kotlin compiler uses this pattern quite frequently (although it’s been a while since I looked at it and I never really got into the internals of the compiler)
We use separation of API and implementation to decrease build times as well. If I have a module A that depends on B-api but not on B-implementation, then I can run unit tests on module A that mock the interfaces defined in B-api without having to build B-implementation.
Kotlin seems to take this approach when there is a interface and the implementation class is hidden. Additionally, factory methods are often defined that make the interface look like it has constructor.
For example, the coroutines library has Job interface, internal JobImpl implementation, and Job top level function for getting the implementation.
Please try NOT to use the suffix .... Impl and (perhaps) even ...Interface
If there is an Interface TheadHandlerInterface
DO NOT use ThreadHandlerImpl.
Please use the implementation details for naming the implementation (MultiCPUThreadHandler implements ThreadHandler, SuperHighSpeedThreadHandler implements ThreadHandler)
Obvios example: Interface AnimalInterface (why using ....Interface?)
There is NO AnimalImpl implements AnimalInterface
BUT Dog implements Animal, Cat implements Animal, Fisch implements Animal
Using semantic names describing the implemeting class helps to make more readable code.
Of cause data structures should use describing names like: Interface List
used as ArrayList implements List, DoubleLinkedList implements List, SortedList implements List.
Thank you all for your responses.
I think that using semantic names for describing the implementing class will be my choice. It is true that other patterns, like class and classImpl, have been popularized by Java. However, after consideration, I’ve also noticed that they use semantic names whenever possible. For instance, they have a distinction between LinkedList and ArrayList for particular implementations of the List interface.
Anyhow, I wanted to know if Kotlin had a standard for this or it was just my preference.