Re: Indexing by multiple keys
Robert Klemme wrote:
On 03.08.2009 14:46, Arved Sandstrom wrote:
Arne Vajh?j wrote:
Robert Klemme wrote:
On 01.08.2009 22:09, Arne Vajh?j wrote:
Arved Sandstrom wrote:
Robert Klemme wrote:
On 01.08.2009 16:21, Arved Sandstrom wrote:
Lew wrote:
For the OP's purpose in particular, it makes more sense to
model an SSN as a String than an int.
In general I agree - I was playing a bit of devil's advocate. I
myself would model an SSN as a string. That the individual 3
numbers making up an SSN are not quantitative entities is
undeniable. But then again, neither are ordinal numbers, and
both the group number and the serial number behave like
specialized ordinal numbers.
I'm still not sold on the idea that there is a checksum for
SSNs. I myself don't see how there can be one. You yourself say
that the three numbers making up an SSN are independent of each
other.
I would model a SSN as an SSN - meaning: since a SSN is not
exactly a number and has more properties than a simple length
(for example, a valid format) I would create a class for SSN
handling. It's likely that it will include a constructor with a
String (or even CharSequence) argument but the internal
representation does not really matter. And it can be changed,
too if you notice that all of a sudden the long you used
initially is not sufficient to hold all the relevant
information. My 0.02 EUR anyway.
How I would approach SSN processing (or SIN or credit card number
processing, for that matter) would depend on where I am getting
the number from, and what I need to do with it. For example, a
number of the government applications I am helping to maintain
deal with SINs, but we get them electronically from trusted
partners, and so there is no need to deal with them other than as
opaque strings.
If OTOH the SSN/SIN was being typed in by a clerk I'd consider
validation of some sort. It won't be perfect but it'll catch some
typos.
Even with validation String would probably be a better format than
int or int's.
Like matching the string against \d{3}-\d{2}-\d{4}.
I would not want to go with plain String in an OO language if there
must be validation. IMHO that approach is only justifiable in the
light of performance issues. The default for me would be a separate
class with ensures all the invariants that are needed for an SSN in
the application.
I disagree.
It comes in as string, it is persisted as string and i can not think of
any operation to be done on it that will not work fine on a string.
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.
It is not particular OO to convert data to unnatural forms.
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.
When I stated earlier that I would contemplate Robert's design for an
SSN class if validation was demanded, I would still store the actual
SSN as a String, with no structure. I am not sure that Robert was
suggesting otherwise himself.
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.