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

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.