I suppose you could set a default value for all these values
And only override what you need
You can also use a map
Copy code
interface IA {
    val aMap: MutableMap<String, String?>
You  are misunderstood, a1 may mean name, a2 may mean phoneNumber in real production
I am planning to use multiple inheritances through Kotlin Deletegate
Such as
I don't know Can Golang's Implicit interfaces help me
Zero boilerplate delegation in Kotlin
🤔, I think here is the
boilerplate code
If you make your properties
instead of
, then you could do this:
Copy code
class Human : IAnimal by Animal(), HandAble by Hand(), FootAble by Foot()
class Cat : IAnimal by Animal(), FootAble by Foot()

interface IAnimal {
    val head: String?
      get() = null
    val heart: String?
      get() = null

interface FootAble {
    val foot: String?
      get() = null

interface HandAble {
    val hand: String?
      get() = null

class Animal : IAnimal
class Foot : FootAble
class Hand : HandAble
But you would need to override the field if you want it to have any other value than
so, they are useless now😅
planning to use multiple inheritance is about the opposite of wisdom if i've ever heard it.
I use it just for bean, my user case is backend's vo,po,dto,pojo etc, so it would not let the code become more complex, just for reuse my data class and I do not need to write lots of repeat code, another benefit is when the requirement changed, I just need edit one place rather all of the kind of bean
sounds like my rationale for same. before i got wisdom lol
you are describing taxonomical traits as the goal, iiuc. you will have a bit easir of a time with every e externalizable form and serialization and bytecode enhancement for instance if you created a set of traits as enums to mark your objects via aggregation
the code will not grow or be painful and you are far less likely to hit internal limitations of MI
you can assign code to enum members that specializes a function based on trait without ever running out of rope due to an inheritance gotcha that btw, might not be solely the jvm runtime
some might suggest your taxonomy be defined as sealed classes. i'd say that would also avoid MI.
Ok, thanks for your reply( though I'm not made complete sense of above ), I will find out a way to solve it (kapt,code generation etc), and I forgot to mention that PO always extends a BasePO class. So I had to use multiple inheritances by delegate if I want to avoid other bean types have relations with BasePO class