I'm creating an interface with couple properties &...

# getting-started

[polendina]

I'm creating an interface with couple properties & methods. I want to implement that interface by couple other varying classes each with its own implementation.
I want to implement the methods of each class, each within its own file, because each method is complicated enough that I want to capitalize on incremental building, whenever I make a change to any method. (i assign each of these functions all at once when implementing the encompassing class)

Now, because each method is defined in a separate file, I can't access the properties/other interface methods within each separate function. The only way I found was to have those functions as extension functions, but it kinda causes API pollution, as I later on have to assign them back again when overriding the interface.

[Klitos Kyriacou]

Something like the following?

MyInterface.kt

package a.b.c
interface MyInterface {
    fun methodA()
    fun methodB()
}

Class1.kt

package a.b.c
import a.b.c.internal.Class1MethodAImpl
import a.b.c.internal.Class1MethodBImpl

class Class1 : MyInterface {
    fun methodA() = Class1MethodAImpl(...)
    fun methodB() = Class1MethodBImpl(...)
}

Class1MethodAImpl.kt

package a.b.c.internal
fun Class1MethodAImpl(...) { TODO() }

Class1MethodBImpl.kt

package a.b.c.internal
fun Class1MethodBImpl(...) { TODO() }

I don't think you can totally avoid what you call "API pollution", but you can possibly minimize the risk using package naming.

[polendina]

you can possibly minimize the risk using package naming

I indeed had to encapsulate the code using packages instead of class, with top-level properties/methods everywhere now.

I naively tried to use extension functions with object singletons, then call them when overriding the interface method, but It sure resulted in a StackOverFlow

[Daniel Pitts]

Extension functions don't handle runtime polymorphism, so you can't use them for inheritance hierarchies.

[Daniel Pitts]

If each method is large enough to be its own file, perhaps you need to find a better way to decompose the logic in the methods. It could be that the abstraction you've chosen doesn't quite work cleanly with OOP.

[polendina]

@Daniel Pitts Sorry for the late reply.

It could be that the abstraction you've chosen doesn't quite work cleanly with OOP

Is there a way for me to tell whether that's the case?

[Daniel Pitts]

If it feels too big, it probably is. What’s too big depends on too many things to give a simple answer over slack on a abstract problem.

[polendina]

I was already struggling with having a coherent overview of my backend design.
Would you rather recommend any resources for OOP design?

[Daniel Pitts]

Start with searching for “solid” principles and reading up on them.