class delegating

i dont see how an interface would be helpful in the shown usecase

@jkbbwr: can you elaborate on the interface idea?

#req kotlin T-shirts

make it happen Jetbrains

take my money plz

for my given example the only 2 methods I see is to either reimplement the Model in the android environment to add the method directly to it or put the Method somewhere else (utility class). Both seems less ideal then an extension function

or you can have composite View, that provides Method and encloses Model

@danijoo: where do you define those extension methods? in AccountExt.kt right next to Account.kt?

AccountExt

because Account should not know of this - its a class thats reused by android and serverside code

so it does not know about UI at all

Sure account shouldn't but either the UI should, or a class should understand both account and UI to draw one to the other

yes but then you have a full class for something that can be done easily by a oneliner method. Isnt that one of the strong points of kotlin to not require to write those unneccesary classes

and you need place for these oneliners :] class it is

Why not write functions rather than extension functions

Question: how many constructors does this class have?

class Person {
    constructor(parent: String) {
        println("foo")
    }
}

Disclaimer : the one in the code is a "secondary" one

because a function to do the same would look less fancy ;)

AccountUtils.getAccountImage(account)

vs

myAccount.getImage()

the last one feels way more natural imo

danijoo: all you have to be careful about is, if you got different

.getImage()

extension methods in different parts of your UI, you could mix them up fairly easy ^^

yeah ofc ^^ i see how this way can lead to confusion

but I think if you look at the point where the function is used, it will make the code more clean with an extension function instead of some Utility class or a helper function

still the problem is: where to put that extension function 😛

I still think it should be a method of the UII

guys, this discussion looks pretty #C09222272 at this point

did I started it? Shame on me!

Could you please bring some light at the

constructors

above?

My understanding is that class has only one constructor, the one that appears in the code with the parent:String parameter

yes