Of course, it does not (in most cases) allow us to solve problems, which could not be solved by more traditional object-oriented or function-oriented approaches, but in some cases, it allows us to do things faster and in a more concise way. The context-oriented approach in Kotlin allows solving many problems in a concise and easily maintainable way. How to use nested contexts to organized complicated data flows.īut, both cases deserve a detailed explanation and it is better to write another article for each of them.How to add static typing to a dynamic typed structure via the decorator context in Kotlin.I planned to add two more examples to this article: And still, it is a very powerful technique when used with care. Also, such a simple construct does not treat well inner value scopes and GC on Variable inside the scope (one needs to use a weak hash map for that). For example, hash map lookup has an impact on performance. Of course, such an approach has numerous limitations. Here the context stores all field values for all objects and effectively adds variable while context exists. For that, we usually define an interface and few instances like : interface IntMapper That is what extensions for: fun Int.map(): String = toString()īut seldom one wants this behavior to be different in different places. One quite frequently wants for some kind of behavior to be added to the existing class. Here is an example that appeared in a discussion about custom mappings.
This time I want to go deeper and show a more complicated real-life example of the same approach. This article is a follow-up on my previous article on context-oriented programming (I was quite delighted to find that some guys in Kotlin community started to use abbreviation COP for it already).
0 kommentar(er)
