Is there any way kotlin lang features can help me simplify using a builder pattern (from java code) ...

# getting-started

[Colton Idle]

Is there any way kotlin lang features can help me simplify using a builder pattern (from java code) that needs IF checks around two of the chained methods?


Examp;e:
SomeBuilder().
.addA() <=== this should be conditional
.addB()
.addC()
.addD() <=== this should be conditional

I can split it apart, but somehow doing it inline would be a lot cleaner

[hfhbd]

Is the builder mutable (mostly the case) returning this or do you get a new builder after each .addX()? If mutable, just use apply

[Colton Idle]

looks like a new builder. let me try apply though. forgot about that

[Pablichjenkov]

I some times face these problem. More specifically to instantiate an object that requires the dependecies in certain order. What I do is split the process in several build steps.
Sort of: B1, B2, B3
Then do
B1.start() // it returns B2
.doB2Stuff() // returns B3
. build() // returns the desired object.

[Colton Idle]

yeah, I think the apply option should work in my case. even though i do get a new builder each time the compiler doesn't seem to complain.

[Pablichjenkov]

Sounds good. My technique above is more oriented to, when the dependencies require specific order.

[Colton Idle]

yeah. im basically writing a long builder from Android, but there are a bunch of api versino checks i have to write. if i dont write them, then i crash, so i just need some conditionals

[Klitos Kyriacou]

Just because the compiler doesn't complain, it doesn't mean the apply method worked as you intended. If each builder method returns a new builder, then using apply will work but you won't actually build anything.

This is what happens:

val obj = SomeBuilder().apply {
    if (cond1) addA() // returns a new instance, which gets discarded
    addB() // returns another new instance, which gets discarded
    build() // builds the original empty object without addA or addB
}

[Klitos Kyriacou]

A possible workaround:

val obj = SomeBuilder()
    .let { if (cond1) it.addA() else it }
    .addB()
    .build()

[Albert Chang]

I would be very surprised if anyone creates an immutable builder class as there are literally zero advantages.

[Colton Idle]

Hm. Maybe someone can help then because I'm trying with this https://developer.android.com/reference/android/os/StrictMode.VmPolicy.Builder

[Colton Idle]

And it's kinda tough to tell if it worked or not.

[Colton Idle]

So I'm trying to string a bunch of detect statements

[Klitos Kyriacou]

The methods return this, not a new object. For example: https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/os/StrictMode.java#529

[Colton Idle]

Detect all is not what I'm using though. I'm using all of the fine grained detect methods. I will try to look closer when I'm back at my desk

[Youssef Shoaib [MOD]]

I think defining a runIf might be good here.

inline fun <T> T.runIf(condition: Boolean, block: T.() -> T): T = if(condition) block(this) else this

Edited to actually make it a run 🤦🏼‍♂️

[Daniel Pitts]

I would use block: T.()->T personally, since you won't need to use it. in the lambda.

[Daniel Pitts]

builder.runIf(someVersion) { useVersionFeature() }

[Youssef Shoaib [MOD]]

Agreed. That was my intention, but I messed it up lol

[Colton Idle]

okay. it does look like the "enable" method returns this. so i should be good with apply. thank you all

[Klitos Kyriacou]

All of this confusion was caused by poor Android documentation. If it explicitly specified that it returned this, we wouldn't be discussing this.

[Colton Idle]

I suppose I still forgot that apply was the right thing to use. so @hfhbd tip was helpful 😄