What is the easiest way to extend an

Map

? I tried extending

HashMap

but it is final. When I extend

Map

I have to implement all types of body functions like

containsKey

,

containsValue

,

get

,

isEmpty

and properties

entries

,

keys

,

size

and

values

Perhaps

delegate

by?

Try `AbstractMap`/`AbstractMutableMap`. Then you need to implement only a set or mutable set of entries.

@Alowaniak not sure how

@Robert https://kotlinlang.org/docs/reference/delegation.html

When using the

AbstractMap

, how do I set the initial values? As I can't use

mapOf

to bootstrap it..

You would need to define the appropriate constructor, and then a helper function like

robertMapOf(vararg Pair<K, V>)

or

Map<K, V>.toRobertMap()

From a design perspective, it’s never a good idea to extend a collection --unless you have some particular data structure need. I suggest you use composition, initialize your type with a map, and implement just the methods you need. Maybe with good names, meaningful to your domain.

I can’t believe nobody mentioned extension functions yet.

@Matteo Mirk I don't understand. If I have a map of items consisting of key-value, it would be wasteful to composite a list and re-implement all the methods like

contains

etc. Instead I just extend the existing class with methods and add some new ones. I don't see how that is "wrong"

Well, depending on how simple you want to go, you could do

class RobertMap(vararg entries: Pair<Int, String>) : AbstractMap<Int, String>() {
    override val entries: Set<Map.Entry<Int, String>> =
        Collections.unmodifiableSet(entries.mapTo(mutableSetOf()) { Entry(it.first, it.second) })

    private class Entry(override val key: Int, override val value: String) : Map.Entry<Int, String>
}

which would let you use

val map = RobertMap(1 to "one", 2 to "two", ...)

Aweomse! It doesn't seem to recognize

Colletions

but maybe that's because I'm in a MP project. So I thought an unmodifiable Map would be cheaper than a mutable one. But from the code I guess this is not true; as it is change to mutableSet before it becomes the unmodifiable set?

Yeah, sorry,

Collections.unmodifiableSet

is a Java stdlib function. I was optimizing for readability / LOC. You could save it more efficiently and use your own implementation of an abstract set to access it.

@Robert Composition doesn’t mean reproducing the whole interface of an associated object. Inheriting from a collection, and in general from a class you have no control over, is a bad idea because you’re forced to conform to its interface and internal representation, which maybe you don’t want (although there are use cases for it). The important question you want to ask yourself is: why do you need to extend a Map, what are you trying to achieve? If you need to build an enhanced version of a Map data structure (which means ALL Map interface + your methods or customized behavior) then okay go and inherit from

AbstractMap

, but it’s seldom the case. If instead you need a domain object that can be backed by a map, then I strongly advise to use composition and create your domain-specific interface, which of course won’t replicate any of the Map’s interface. If you need more explanation I can provide some code example, just ask.