In short, you can just about make every class besides your application API and domain internal. But it made me think how much I could make internal, and as I’ll show you, it so happens to be quite a lot, really. In addition, Kotlin does not have the concept of package protection, it only has 2 visibility modifiers: private and internal. By default, Kotlin makes everything public.
When you start to use Kotlin, you come across another hurdle. This is mainly due to what I just said, by creating structural layers in our packages, which makes package protected classes a lot harder to use. In addition, a lot of us tend to make a lot of things public. And I’m starting to realize this isn’t really the right way forward. To this day, I still tend to layer my packages into their structural counterparts like be. and be. This little piece of advice, and quite a few others from that talk, got me thinking about how I structure my applications. At the end of the presentation, Simon gave one specific piece of advice. If you’re already accustomed to clean architecture, you’re familiar with the notion of modules: you’ll probably have separate modules for your application, domain and infrastructure layers. Recently I had another look at Simon Brown’s 2016 Devoxx talk about building modular monoliths. In addition, I like the concept of clean architecture, something I have talked about in lengths in previous articles.
To me, it’s the language that Java was meant to be, providing a plethora of features and all the power of the JVM. Let me start off by saying that I really like Kotlin.
0 kommentar(er)
