2

I have a set of component interfaces

interface ITest<I> { operator fun invoke(p: I) } interface OTest<O> { operator fun invoke(): O } interface IOTest<I, O> { operator fun invoke(p: I): O }

and a corresponding functional interface

interface TestAdder<T> { fun add_f(p: T) {} //default impl }

that gets inherited to add the components from above to respective (functional) collection interfaces

interface ITestSet<I> : TestAdder<ITest<I>> { val i_v: I fun i_f1(p: I) {} // default impl fun i_f2(p: I) {} // default impl fun i_f3(p: I) {} // default impl } interface OTestSet<O> : TestAdder<OTest<O>> { val o_v: O fun o_f1(p: O) {} // default impl fun o_f2(p: O) {} // default impl fun o_f3(p: O) {} // default impl } interface IOTestSet<I, O> : TestAdder<IOTest<I, O>> { val i_v: I val o_v: O // same as ITestSet<I> fun i_f1(p: I) {} // default impl fun i_f2(p: I) {} // default impl fun i_f3(p: I) {} // default impl // same as OTestSet<O> fun o_f1(p: O) {} // default impl fun o_f2(p: O) {} // default impl fun o_f3(p: O) {} // default impl fun io_f1(p: I): O ... }

So far, so unnecessay: ideally IOTestSet<I, O> should inherit the functionality defined in ITestSet<I> and OTestSet<O>:

interface IOTestSet<I, O> : ITestSet<I>, OTestSet<O>, TestAdder<IOTest<I, O>> { fun io_f1(p: I): O ... }

but obviously the TestAdder<T> interface introduces inconsistency within the inheritance chain.

This smells like an age-old, archetypal paradigm (and probably even an XY) problem, still it seems I have to ask:

Q: How to compose this inheritance chain?

Or what is the established/much better/less and not unnecessarily convoluted/more elegant design pattern?
Improve this question
2
  • 1
    So what type of thing is the add_f method of IOTestSet going to take? ITest<I>, OTest<O>, or IOTest<I, O>? If you want overloads for all types to exist, inheritance won't work here because, (long story short) type erasure. Commented Sep 1, 2022 at 10:10
  • @Sweeper ya, the idea is to have an overloaded f_add function on all [IO|I|O]TestSet interfaces accepting their respective IO|I|O]Test interfaces. I guess I could externalize the [i_|o_}f<n> functionality into yet another set of Interfaces, inherit them and have a specific add_f method on all TestSets. Any other way you can think of to redesign? Commented Sep 1, 2022 at 10:32

1 Answer 1

Reset to default
3

As for why this doesn't work, it is because you are inheriting from the same interface, just with different type arguments. And the reason why you can't do that is explained here.

Composition

When inheritance doesn't work, we can try composition. (See also: "Prefer Composition Over Inheritance")

Rather than having ITestSet and OTestSet inherit TestAdder, which is the root cause of your "inheriting from the same interface but with different type arguments" problem, add get-only properties of type TestAdder to ITestSet, OTestSet, as well as IOTestSet.

Then IOTestSet will be able to inherit ITestSet and OTestSet. The full code is as below:

// I have added variance modifiers where appropriate interface ITest<in I> { operator fun invoke(p: I) } interface OTest<out O> { operator fun invoke(): O } interface IOTest<in I, out O> { operator fun invoke(p: I): O } interface TestAdder<in T> { fun add_f(p: T) {} //default impl } interface ITestSet<I> { val i_v: I val inputAdder: TestAdder<ITest<I>> fun i_f1(p: I) {} // default impl fun i_f2(p: I) {} // default impl fun i_f3(p: I) {} // default impl } interface OTestSet<O> : TestAdder<OTest<O>> { val o_v: O val outputAdder: TestAdder<OTest<O>> fun o_f1(p: O) {} // default impl fun o_f2(p: O) {} // default impl fun o_f3(p: O) {} // default impl } interface IOTestSet<I, O> : ITestSet<I>, OTestSet<O> { val ioAdder: TestAdder<IOTest<I, O>> fun io_f1(p: I): O }

Implementing the interfaces

From what I can see, you can still implement this new set of interfaces in the same way as you did before - e.g. to implement ITestSet<String>, you just do:

class Foo: ITestSet<String> { override val i_v: String = "Some String" override val inputAdder = object: TestAdder<ITest<String>> { // implementation goes here... } }

Note that it is possible to provide a default implementation for inputAdder:

interface ITestSet<I> { val i_v: I val inputAdder: TestAdder<ITest<I>> get() = object: TestAdder<ITest<I>> { // implement your thing here... } ... }

but this recreates the object every time you access inputAdder, which may not be the semantics you intended.

This brings me to another difference of this design, compared to your original design: you allow implementations to implement inputAdder, outputAdder, and ioAdder in whatever way they like. This means that they are not necessarily implemented so that e.g. each ITestSet always has the same inputAdder, like in your original design, where the "inputAdder" of each ITestSet is always itself. Of course, this isn't a problem if you have total control over the code.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Because I want those three TestSet interfaces to represent individual types as well, as clean as possible, I just went for a third set of functional interfaces - but your approach is likely the more idiomatic design pattern, and overall great advice. Thanks for the thorough snswer!

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.