if I want to leverage `expect`/`actual` mechanism and I want to have abstraction for testing, would ...

# multiplatform

[Marko Novakovic]

if I want to leverage `expect`/`actual` mechanism and I want to have abstraction for testing, would this be good practice or there is some other way?

interface AccountStore {
    val account: Flow<Account>
}

class AccountStoreImpl(platformAccountStore: PlatformAccountStore) : AccountStore {
    override val account = platformAccountStore.account
}

expect class PlatformAccountStore {
    val account: Flow<Account>
}

AccountStore is abstraction and it’s used for testing and PlatformAccountStore is, as name says, where I will implement Android and iOS specific behaviours

[Pablichjenkov]

You can place it in the sourceSet for androidApp and iOSApp inside the "shared" library folder. Or you can define it in the application code. Either in Kotlin in the case of Android and swift in the case of iOS

[Marko Novakovic]

I can skill `expect`/`actual` altogether. I didn’t see the forest for the trees 😄

[Marko Novakovic]

it will not force me to write actual implementation tho. but it’s not a big deal

[Pablichjenkov]

Exactly 💯

[Pablichjenkov]

I have the same feeling

[Marko Novakovic]

thanks 🙂

[russhwolf]

Once you have an interface for something, having an expect class is almost always redundant and just gives you another layer you have to change any time you adjust the interface. If you want to have a default in common without needing to inject anything, I usually do something like expect val defaultAccountStore and then the actual can be the platform implementation.

[Marko Novakovic]

yes expect with interface feels weird, thanks