Indexing by multiple keys

[Lew]

You can use whatever keys you want in a HashMap.
You can also use multiple hash-maps if you're keyspaces aren't disjoint.

Map<String, Person> byName;
Map<SocialSecurityNumber, Person> bySsn;
Map<Color, List<Person>> byFavoriteColor;

Great examples.

For that last I proffer

Map <Color, Set <Person>> byFavoriteColor;

to prevent duplicate entries in the target collection.

A word to the wise - this technique increase the programmer's responsibility
to clean up references. It's all too easy to leave a 'Person' reference
buried in 'byFavoriteColor' that you removed from 'byName' and 'bySsn'.

With JPA, @Entity and judicious use of @OneToMany and siblings to inject
member collections, you mitigate the risk of reference retention because you
don't maintain multiple long-lived independent structures.

EntityManager and its related mechanisms provide useful resource and entity
object management. The programmer can't abdicate responsibility, but the JPA
provides methods that simplify control.

For example you could create the cited 'Map's at need rather than as permanent
edifices. You do a little query, retrieve one or another useful collection of
entities expressing one or another useful relationship, do something useful
with those objects, then pass the objects out of scope, mayhap closing an
entity manager on the way out. There's less chance of packratting with that
idiom.

JPA managers also unify managed instances so that you don't get entity bloat.

 

[Arne Vajhøj]

I agree, but it is also not a String.

It is a type in-and-of itself.

come on people, we're OO programmers, use classes over primitives!

String is a class.

If it should be a custom class, then we should have a purpose
for doing so.

Beyond the "cuteness" factor.

More code (measured in functionality not KLOC) => higher cost.

Arne

 

[Arne Vajhøj]

It's not that there are operations that would not work on a String. My
point is that there are _too many_ operations that work on a String that
are either superfluous for a SSN or actually do harm (for mutable
strings). From what I have read a SSN is significantly important and
special enough that a dedicated class is warranted.

Strings are not mutable in Java.

And encapsulating String's in classes to make String's methods
unavailable seems superfluous to me.

Whatever "unnatural" means in this context. I find it most natural when
working in an OO language to model important entities of the real world
as separate classes and not try to cover everything with basic types.
After all, that's what OO is about.

No.

Keywords are: information hiding, data abstraction, encapsulation,
modularity, polymorphism, and inheritance.

Good OO is using basic types if that makes most sense.

As you rightly assumed, I wasn't. If Arne's argument were followed,
there would be no point in having other classes as String in an
application at all because all the data comes in as strings and goes out
as strings. (Of course I am exaggerating here - but just a bit.) ;-)

Good programming is not about doing things just for doing it.

Good programming is about doing things for good reasons.

If you have an app that:
* only takes input, persist and produce output as strings
* does not have a need to bundle data together
* does not have a need for any methods on the data besides
those provided by String
then you don't need any classes except String.

I don't think I have ever seen an app meeting those
requirements, so your point is extremely irrelevant.

Arne

PS: And you were exaggerating more than a bit. Claiming that
not using a custom class for SSN is the same as meaning
no custom classes at all is off the scale for
exaggerating.

 

[Daniel Pitts]

String is a class.

If it should be a custom class, then we should have a purpose
for doing so.

Beyond the "cuteness" factor.

More code (measured in functionality not KLOC) => higher cost.

Arne

String is a class, but it is a fairly primitive abstraction. The
purpose of using a custom SSN class is provide an easy way to handle
invariants in one place. SSN's have a definite structure which can be
checked when created and modified.

The cost of having an SSN class is less than the cost of sprinkling SSN
verification code throughout the rest of the app.