I encountered code like this in some project: ```c...

# getting-started

[y]

I encountered code like this in some project:

class Concrete {
  override val name: String,
  // ...
} : FooInterface, BarAbstractClass<SomeType>

interface FooInterface {
  val name: String
  // ...
}

abstract class BarAbstractClass<T: SomeTypeBound>() {
  abstract val name: String
  // ...
}

which name does Concrete have? does it have two different ones?

[Jaap Beetstra]

No, there is just a single name. If you refer to obj.name it doesn’t matter if obj is of type Concrete, FooInterface, or BarAbstractClass. If it’s the same instance, it’s the same name.

[Klitos Kyriacou]

It has a single property, name, with a single getter that overrides the abstract getters of both the interface and the abstract class.

[y]

I see. thanks everyone.

[y]

so in this case, FooInterface, which in fact only has a single field name, is probably there because it exposes an interface (heh) that allows accessing the deriving class's name without specifying the type bound when taking or returning a Concrete.

[y]

Concrete also inherits from more interfaces.
could we have achieved the same result by taking/returning a BarAbstractClass<*> instead?

[Daniel Pitts]

I'm not sure I understand your question, but here is some info that might help: Using an interface allows any approach to implementing the abstract behavior, where an abstract base class fills in some of the blanks for you, possibly in ways that can't be overridden. Also, any class can implement multiple interfaces, but only extend one base class.