Hey guys, what is the main difference between `expect class` and an `interface`, defined in the com...

# multiplatform

[electrolobzik]

Hey guys, what is the main difference between expect class and an interface, defined in the common part? It looks like in both cases I can define signature in the common code and then implement platform specific implementation. What is the main point of using expect class instead?

[Javier]

• Another class cannot inherit multiple classes, so you can limit what your code can do.
• A class can have state, an interface cannot.

[electrolobzik]

@Javier it looks like one can’t declare any state in expect classes. I can add fields the same way I can declare them in an interface.

[Alexander Zhirkevich]

Expect class can declare a constructor and can be instantiated from the common sourceset. Implemented interfaced can only be created in platform source sets and injected to common. I prefer interfaces over expect classes as it provides more flexibility and abstraction and easier to test.

[Pamela Hill]

This might help: https://kotlinlang.org/docs/multiplatform-expect-actual.html#expected-and-actual-classes

[Pamela Hill]

The most important rn to know is that expect/actual classes are in Beta.

[electrolobzik]

@Alexander Zhirkevich In the most of cases what I saw, expect classes were used in situation, when platform specific implementation required extra some extra information. The most common case: Context in Android. And the actual class just implemented a constructor with Context or something like that. I don’t understand if are there any advantages of expect class over regular interface in this case.

[Pamela Hill]

Usual pattern is instead of expect class, to use normal interface and expect funs (it's in the docs and default sample for kmp.jetbrains.com + AS demo

[electrolobzik]

@Pamela Hill For me it is not totally clear from this doc if there are any other cases, when expect classes can be useful. There are some in the doc, like already existing platform type. But it is not clear if this list is exhaustive.

[electrolobzik]

And it looks like some library maker also don’t understand that difference and use expect classes instead of interfaces sometimes.

[electrolobzik]

So as I understood from this discussion, besides some corner cases, described in the doc, the only reason of using expect class is the case, when one needs to instantiate the class inside the common code and DI is not possible or convenient (like creating exception). In all other cases when we can inject platform-specific implementation into the common code or are creating the instance in the platform code it is much correct to use interfaces.

[electrolobzik]

Example: https://cashapp.github.io/sqldelight/2.0.1/multiplatform_sqlite/#constructing-driver-instances

[electrolobzik]

I don’t see any reason of using expect class here.

[electrolobzik]

@Pamela Hill One more interesting thing in defence of expect class . There is a pretty nice support from the IDE side when we use them instead of interfaces: one can see if the class has or not implementations on all platforms and allows to quickly create one, creating all required directories and files.

[Vladimir Vainer]

And I like the naming convention where the actual file name is Foo.ios.kt Foo.android.kt
It's much easier finding the correct implementation.