Are interfaces still a good idea in Kotlin? I ask ...

# announcements

[Rak]

Are interfaces still a good idea in Kotlin? I ask because most of the time there is only one implementing class and mocking is a non-issue in tests.

[crummy]

if there's only one implementing class I almost never write interfaces (in Java too)

[nfrankel]

exactly
the issue is not kotlin specific
it’s about over-engineering
https://blog.frankel.ch/are-you-guilty-of-overengineering/

[Rak]

Prior to the advent of mocking libraries like mockito, creating your own implementations for unit testing was a valid approach.

[Rak]

Also, I can’t help thinking there is something about classes exposed ONLY to the interface not having to be recompiled when the implementation changes (but not the interface). Is there anything to that?

[Tyler Hodgkins]

Re: the original question, how else can you expose a shared, polymorphic API?

[Tyler Hodgkins]

If you’re building a simple user experience or tool, chances are you can get away with building it quick and rebuilding it later.

If you’re building a framework, taking the time to ensure your code is properly encapsulated & follows a rational design pays dividends.

[Tyler Hodgkins]

I think the biggest risk of over-engineering is that it’s too easy to engineer the wrong long-term solution. Not many people have the experience/forethought to put the correct solutions in place, thus it is generally a better option to opt for a more simple structure in the short-term…

As long as that simple structure leaves room for future refactoring - it’s not fun when you have to spend 3 months refactoring some tiny subsystem because it wasn’t built in a way that facilitates refactoring 😞