https://kotlinlang.org logo
Title
a

Andrew Gazelka

01/27/2019, 8:37 PM
is it bad practice to start interfaces with
I
?
I think it can help but kinda sucks with IntelliJ autocomplete, so I would think maybe it is not a good Kotlin/Java standard
n

nfrankel

01/27/2019, 8:40 PM
think about this: does Java/Kotlin uses this approach?
1
a

Andrew Gazelka

01/27/2019, 8:41 PM
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.
1
n

nfrankel

01/27/2019, 8:44 PM
i’m not asking whether you see it in project i’m asking whether you see it in the java or kotlin api?
a

Andrew Gazelka

01/27/2019, 8:45 PM
ah, I don't. Probably good to not have an
I
then. Thanks.
👍 1
d

Davide Giuseppe Farella

01/27/2019, 9:15 PM
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
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
n

nfrankel

01/27/2019, 9:32 PM
none of them is better having
I-
and
-impl
means you cannot name your types properly
5
🤔 3
d

Dominaezzz

01/27/2019, 10:08 PM
VideoChannel
?
n

nfrankel

01/27/2019, 10:16 PM
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
l

louiscad

01/27/2019, 10:16 PM
@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.
👍 3
1
g

ghedeon

01/27/2019, 10:19 PM
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
.
n

nfrankel

01/27/2019, 10:20 PM
@louiscad you might strongly disagree my point still stands 🙂
😡 1
g

ghedeon

01/27/2019, 10:25 PM
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).
d

Davide Giuseppe Farella

01/27/2019, 10:33 PM
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"?
4
l

louiscad

01/27/2019, 10:36 PM
@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?
2
d

Davide Giuseppe Farella

01/27/2019, 10:38 PM
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-
?
l

louiscad

01/27/2019, 10:49 PM
@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.
2
h

hudsonb

01/27/2019, 11:09 PM
I always try to avoid the 'Impl' suffix. Does it still happen sometimes? Yes. Is it hideous? Yes.
"...default implementation is provided", so call it DefaultThing instead of ThingImpl
g

ghedeon

01/27/2019, 11:20 PM
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.
2
d

Davide Giuseppe Farella

01/28/2019, 5:03 AM
@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
u

ursus

02/06/2019, 5:44 AM
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
id rather have ImplFoo, or DefaultFoo