On a specific class I want to define many methods (let’s say 50), but I want to group these methods ...

# getting-started

[Daniele B]

On a specific class I want to define many methods (let’s say 50), but I want to group these methods in separate files by topic (let’s say files with 4-5 methods).
I was able to achieve this by defining these “methods” as “extension functions” instead? Do you see anything particularly wrong with that?

[Dmitry]

There is nothing wrong with that, really.

But are you sure that you need a class for those methods? You will not have access to private members of a class in extension functions.

Maybe you could just create top-level functions?

[Daniele B]

I am defining the class properties as “internal”. In this way I am verifying that I am able to read/write them from each extension function.

[Daniele B]

I just instantiate the class once, and then I am able to call any extension function on it.

[Daniele B]

in order to read/write class properties from extension functions, is the only requirement to define them as “internal” instead of “private”?

[Dmitry]

internal visibility means that your properties will be visible to everyone in your module.

Is that OK in your scenario?

[Dmitry]

My suggestion for creating extension functions is to always use only public API that is available to you from that class.

In that case extension function would be exactly that - extending your core API with additional utility.

For example: you have List collection.

It has .get() method to get element of a list.
To get last element of list you could write: list.get(list.size - 1).

So, you can achieve your goal using “core” API of a class.

But with extension function you can extract this code, to reuse is later as as list.last().

Your extension function in this case uses only public API (method get())

[Daniele B]

@Dmitry yes, I understand what you are saying. The use case you are presenting is very popular and makes a lot of sense.
Here, I am trying to use it in a different context. As a means to be able to organize class “methods” across different files.
In my specific case, defining the class properties as “internal” (and hence being in able to access them from anywhere in the module) would not be a big issue.

[Daniele B]

I am using it inside a KMP shared module

[Daniele B]

“internal” is still better than “public”

[Daniele B]

My use case is a class that holds the state for the application. And the extension functions would be the “state reducers”, the functions that modify the state.

[Daniele B]

I find it convenient to group them in separate files, depending on which is the section of the app they are dealing with

[Dmitry]

Aha. I see.
Interesting.

IMO, if having visibility is not a problem for you (as you said you have separate module), then I don’t see any issues with approach.

It’s actually interesting. Traditionally reducers are accepting state as a first argument.
In your case - reducers are referring to state as this .

[Daniele B]

yes, I am finding this approach very neat
it also makes the code very well organized

[Daniele B]

if you are interested, you can find more info on the last page of my 3-page article:

[Daniele B]

https://danielebaroncelli.medium.com/the-future-of-apps-declarative-uis-with-kotlin-multiplatform-d-kmp-part-3-3-959a2628526d

[Dmitry]

However, personally, I would stick with pure-function reducers.
It kinda makes working with them more easier (to my taste).

[Daniele B]

do you mean in terms of testing?

[Daniele B]

1_75PpLmA_3wku61roD6sy6Q.png

[Daniele B]

with this approach, it’s also very easy to test them, just by injecting/replacing a mock repository