Naming convention for Map<Key,Map<Key,Value>>

[John Jai]

Hi,

I just wonder how you people do naming for a Map<Key,Map<Key,Value>>. Consider if people's age is present in outer map's key and age and email address as key value in the inside map.

say - John < 23, [e-mail]> -> how do you normally name this map - i will have it nameAndAgeEmailMap

[Ove Lindström]

For this type, I personally use AgeOrientedAgeMailMap. I've also seen naming constructions where the "Map containing maps that contains age-email pairs" are described as AgeAgeMailMapMap to "comply" to the JNS-rule that "a collection should state what is contains and the type of collection".

But I have not found a golden rule for this yet.

[Matthew Brown]

Difficult to say, because I'd never use that data structure in that case. It makes no sense to have a mapping from age to email. That structure suggests to be you're expecting each person to have multiple ages, each with it's own email address.

[John Jai]

What would be the data structure (Collection object) I should use then. Is DAO only solution for keeping 3 or more unrelated entities that define a single object?

[Matthew Brown]

Personally, I'd just write a class encapsulating the values, and have a collection of those. List or Set as appropriate, or Map if you wanted to be able to lookup on a unique attribute.

Edit: having thought about the original question a bit more, if I was going to use that approach I'd probably use something like "nameToAgeToEmailMap".

[John Jai]

Ove Lindström wrote:For this type, I personally use AgeOrientedAgeMailMap. I've also seen naming constructions where the "Map containing maps that contains age-email pairs" are described as AgeAgeMailMapMap to "comply" to the JNS-rule that "a collection should state what is contains and the type of collection".

But I have not found a golden rule for this yet.

Oye thanks for replying. But I feel this one very funny - "AgeAgeMailMapMap". Might be it reflects the flaw in my data structure

[Seetharaman Venkatasamy]

John Jai wrote:What would be the data structure (Collection object) I should use then.

why cant you wrap the two obejcts attributes into a Single Object and put into a Collection?

John Jai wrote:Is DAO only solution for keeping 3 or more unrelated entities that define a single object?

probably you are talking about DTO. I dont see any irrelevant between key and value literals

[Ove Lindström]

John Jai wrote:

Ove Lindström wrote:For this type, I personally use AgeOrientedAgeMailMap. I've also seen naming constructions where the "Map containing maps that contains age-email pairs" are described as AgeAgeMailMapMap to "comply" to the JNS-rule that "a collection should state what is contains and the type of collection".

But I have not found a golden rule for this yet.

Oye thanks for replying. But I feel this one very funny - "AgeAgeMailMapMap". Might be it reflects the flaw in my data structure

So do I so I never use it.

[Stephan van Hulst]

I have used something like this in the past:

Map<Entry, Set<Archive>> archivesContaining;

I usually name Maps after what values they are supposed to return, and I include a small hint as to their function. In this case, I had a bunch of archives that contain entries. Ddue to some circumstances I had no control over, some entries could be contained by multiple archives. When I wanted to know which archives contained a particular entry, I could have iterated over all the archives and return all the archives that happened to contain that entry. For performance reasons, I decided to use a map to directly look up which archives contained a particular entry.

Now, I can simply perform a call like this:

Set<Archives> archivesContainingMyEntry = archivesContaining.get(myEntry);

I would have preferred to do it otherwise, but in the circumstances, this seems like the most readable solution.

Don't blindly follow conventions if they don't lead to readable code.

[John Jai]

Seetharaman Venkatasamy wrote:

John Jai wrote:What would be the data structure (Collection object) I should use then.

why cant you wrap the two obejcts attributes into a Single Object and put into a Collection?

You mean to say concatenate the Age & Email strings using a delimiter & use that a single object?

[Matthew Brown]

John Jai wrote:You mean to say concatenate the Age & Email strings using a delimiter & use that a single object?

No - don't do that. I think he means this (which is what I was talking about earlier):

class PersonDetails {
    private String name;
    private int age;
    private String email;
    // etc
}

Collection<PersonDetails> details = ...

[John Jai]

oh ok Mathew... this is what we call a DAO over here... I dont know if it should be referred as DTO as the other person said.

[Matthew Brown]

John Jai wrote:oh ok Mathew... this is what we call a DAO over here... I dont know if it should be referred as DTO as the other person said.

I'd just call it a class.

DAO/DTO are about what you're using them for. I'd expect a DAO to be tied to your persistence layer somehow. It could be a DTO if the purpose is communicating between layers of your application.

[Campbell Ritchie]

Agree with whoever said to wrap name and age into a single class to use as the Key. But beware, beware: some of us have birthdays, and when we have birthdays, our ages change. If our ages change, our ages' hash codes change. Since most Java™ maps are hash-based, when the hash code changes, it will become impossible to find the value back

Try name and date of birth in a class as a key. If you use a Date or Calendar object for the date of birth, you would have to wrap it so as to maintain immutability of the enclosing type.

[Seetharaman Venkatasamy]

Matthew Brown wrote:

John Jai wrote:You mean to say concatenate the Age & Email strings using a delimiter & use that a single object?

No - don't do that. I think he means this (which is what I was talking about earlier):

class PersonDetails {
    private String name;
    private int age;
    private String email;
    // etc
}

Collection<PersonDetails> details = ...

Yes, I meant this