Inheriting and encapsulating collection classes in Java

Question

Suppose I have the following types of data:

class Customer {
  String id; // unique
  OtherCustData someOtherData;
}

class Service {
  String url; // unique
  OtherServiceData someOtherData;
}

class LastConnection {
  Date date;
  OtherConnData someOtherData; // like request or response
}

Now I need to remember when each of the customers connected to each of the services.
I would make the structure:

Map<Customer, Map<Service, LastConnection>> lastConnections;

Or, to be able to search by ids and not have to write all the equal() and hashCode():

Map<String, Map<String, LastConnection>> lastConnections;

Now I could access the LastConnection data by

LastConnection connection = lastConnections.get(custId).get(srvUrl);

All this seems ugly, especially that I have to pass it as parameters to tens of methods expecting map of maps of LastConnections, so I'm thinking of creating my own classes which would look something like that:

class CustomerConnections extends HashMap<String, LastConnection> {
}

class AllConnections extends HashMap<String, CustomerConnections> {
    public LastConnection get(String custId, String srvUrl) {
        return get(custId).get(srvUrl);
    }
}

Ok, I learned already that inheritance is 3v1l, so let's try composition:

class CustomerConnections {
    Map<String, LastConnection> customerConnections;
    LastConnection get(String srvUrl) { 
        return customerConnections.get(srvUrl);
    }
    ... // all other needed operations;
}

class AllConnections {
    Map<String, CustomerConnections> allConnections;
    public LastConnection get(String custId, String srvUrl) {
        return get(custId).get(srvUrl);
    }
    public CustomerConnection get(String custId) {
        return allConnections.get(custId);
    }
    ... // all other needed operations;
}

The problem is that I'm not sure what would be the best approach respecting SOLID principles and all the best practices. Creating classes that do nothing except extending already existing collections seems like multiplying entities beyond necessity, but would make my code more clear (Especially when there are next levels - like Map of AllConnections by month and so on). Any directions?

Answer 1

I would create a dedicated object for storing this information. What you're creating is a manager object, rather than a simple collection.

I wouldn't make it derive from a Map or other well-known collection class, since the semantics of how you store this info may change in the future.

Instead implement a class which ties together a customer and its connection, and inside that class use the appropriate collection class (that you're at liberty to change later without affecting the interface and the rest of your code)

Your customer/connection manager class is more than a simple container. It can store meta-data (e.g. when was this relationship established). It can perform searches on connections given customer info (if you require). It can handle duplicates how you require, rather than how the underlying collection class handles them etc. etc. You can easily slot in debugging/logging/performance monitoring to easily understand what's going on.

Answer 2

Creating classes that do nothing except extending already existing collections seems like multiplying entities beyond necessity

I would change extend to encapsulate. You are hiding the details of how this information is stored. Clients of your class don't need to know how you are providing them with the Customer connection history. I think this is a good idea since you can change the underlying model without having clients of the api change their code.

but would make my code more clear

This is great and is a good reason to do this. YourClass.getCustomerConnection(cId) is much clearer than yourCollection.get(id).get(id).getConnection(). You need to make the life of the people using this code easier, even if you are that person.

(Especially when there are next levels - like Map of AllConnections by month and so on)

Good, then you are planning ahead and making your code extensible. Which is good OO practice. In my opinion the conculsion you have reached on your own is what I would do.