While APIs are not forever, when you make something public, the expectation is that it’ll be there for a long time, and importantly, that it will behave the same way for a long time.Īnything you make public, whether at the source or binary level, will break client code if you make changes to it. The fewer public declarations you have, the fewer things you’re stuck with supporting in the future. Some reasons for minimal APIsīefore we get to the practical part, let’s quickly see some simple reasons for minimizing the API surface of a module. There’s a huge amount of great advice in that item, and most of it won’t be covered here, as the focus will be on the Kotlin implementations of the ideas – so do read it after this article. This is the very first item of Chapter 4: Classes and Interfaces, which further highlights just how important it is. It might be a cliché at this point to reference Effective Java, but like many great ideas, it has an item covering this: Item 15: Minimize the accessibility of classes and members. When designing a library, minimizing your API surface – the types, methods, properties, and functions you expose to the outside world – is a great idea. Each of those modules presents a public API to the outside world, exactly the same way a library does. While the focus of this article is libraries, everything here applies to any project that has multiple modules. This article is also available as a talk, check out the slides and recordings here.

Internal function kotlin