is it bad practice to start interfaces with `I`?

# announcements

[Andrew Gazelka]

is it bad practice to start interfaces with I?

[Andrew Gazelka]

I think it can help but kinda sucks with IntelliJ autocomplete, so I would think maybe it is not a good Kotlin/Java standard

[nfrankel]

think about this:
does Java/Kotlin uses this approach?

[Andrew Gazelka]

like does it require this? Obviously not. Do I ever see it in Kotlin/Java code? Yes. Do I see it in examples in official docs? No.

[nfrankel]

i’m not asking whether you see it in project
i’m asking whether you see it in the java or kotlin api?

[Andrew Gazelka]

ah, I don't. Probably good to not have an I then. Thanks.

[Davide Giuseppe Farella]

I avoid it ad much as possible, the last time I used it it was because I had a TvChannel and a MovieChannel and they had to share an interface and well... We already have a Channel class with Coroutines

[Davide Giuseppe Farella]

If you have to choose between I- and -impl i think the second one si better, since I would want to expose the interface, instead of the implementation

[nfrankel]

none of them is better
having I- and -impl means you cannot name your types properly

[Dominaezzz]

VideoChannel?

[nfrankel]

why not keep Channel?

We already have a Channel class with Coroutines

packages are there to avoid name collisions
avoiding duplicate types name is a good idea
unless the alternative is worse - IChannel

[louiscad]

@nfrankel For the Impl suffix, I strongly disagree, there's plenty of cases where a default implementation is provided, but only the interface of abstract class is exposed, and it's better that way, and there's no better name than specifying it's the implementation with that suffix. For example, there's the internal abstract ContinuationImpl class in Kotlin/JVM stdlib.

[ghedeon]

and instead of risking to have two Channel in one class, with ugly long import to differentiate between them, I'd vote in favor of VideoChannel.

[nfrankel]

@louiscad you might strongly disagree
my point still stands 🙂

[ghedeon]

but yeah, most of the time you don't need this additional I/Impl noise. I'm just not sure that "did you see that in Kotlin?" tells me anything. People are doing a lot of things that you won't see in SDK, and they are not necessarily wrong. Like, many teams prefer TheFoo instead of FooTest because it's easier to navigate in your code like this (search results are better separated).

[Davide Giuseppe Farella]

Can a concrete class live without an interface? Yes, and it would have its name... If one day I decide to create ad interface for that class maybe only for dependency inversion, why should one of them have a fantasy name, instead of just have the impl suffix?

A name could always be found, but if I got a single repository, how should I call the implementation? What should be a concise and well descriptive name of the implementation of repository if not RepositoryImpl? Maybe that will appear only in 2 places in the code, the declaration and the instantiation, why should I make more confusion just because "if I use impl that means I can't find a better name"?

[louiscad]

@nfrankel Your point can stand, but if it doesn't help for naming or hints toward a practical solution, I'd say I don't see the point. Does it help to find a better name for the ContinuationImpl class, or is this name, with the Impl suffix good enough?

[Davide Giuseppe Farella]

Also most propably I'll use Coroutines Channel and my entity Channel tougher in the same class, should I use the full classified name through the code? Should I import as? For which one? Which name should I chose for which of them? Should I remember that import name and use the same everywhere? Should I risk to import something with different name? Why can't I simply add an I-?

[louiscad]

@Davide Giuseppe Farella The difference with the I prefix for interfaces is that interfaces are almost always part of a public API, where name matters much more than for Impl suffix where it is usually in a private or internal class, where renaming doesn't break anything and is just an IDE action away. Because of that, you need to think at least twice about the reach of the API you are making and its use cases before settling with a name.

[hudsonb]

I always try to avoid the 'Impl' suffix. Does it still happen sometimes? Yes. Is it hideous? Yes.

[hudsonb]

"...default implementation is provided", so call it DefaultThing instead of ThingImpl

[ghedeon]

the problem with DefaultThing is that it suggests that it might coexist with a few other NonDefault implementations. But it's not true in cases where the only purpose of the interface was Dependency Inversion. The Repository example by @Davide Giuseppe Farella is pretty good. You don't have a hierarchy of repositories. In the ideal world, all you want is FooRepository. but because of DI you name it FooRepositoryImpl since the desired name is taken by the interface.

[Davide Giuseppe Farella]

@louiscad yep, agree, that's what I already said on the first message here 😋 but that was a private app ( also something small and I was experiment ) so, why not? Maybe I will find a better name, but I would avoit to copy the name of a such "common" API like Channel

[ursus]

Impl sufix always confused me on what the type is, since sufixes in my brain command type hierarchy FooActivity, BarActivity both extend Activity -- but FooImpl and BarImpl on quick glance look theyre both related since theyre both Impl

[ursus]

id rather have ImplFoo, or DefaultFoo