is it bad practice to start interfaces with

I

?

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

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.

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

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

I

then. Thanks.

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

none of them is better having

I-

and

-impl

means you cannot name your types properly

VideoChannel

?

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

@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.

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

.

@louiscad you might strongly disagree my point still stands 🙂

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).

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"?

@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?

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-

?

@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.

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

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.

@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

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