Jon replies:
> What you are saying is that you can implement this in a good or bad way.
> Either way it will work. But why implement the bad option if you can
> just as easily implement the good?
I can't speak for others (of which there were plenty), but for me, that
pretty much does it. When you frame it all in this way, it looks pretty
small, really.
I expect that all of us have confronted the necessity of interfacing with
legacy junk. As much as it might be distasteful, there's really no choice
but to support those ugly-formatted means of data interchange. But let's
ensure that the ugly is only skin deep. You can provide an ugly interface,
while still doing the meat of your implementation "the right way".
You have a potential for a bug in the FullName getter. What happens in my
case (my first name being "Christopher", which is 11 letters long)? I think
you'll get back a buffer that's 21 chars long, with my full name, rather
than truncating the "r" off the end. You need to add logic for that
truncation, which is what I was doing in my sample with the call to
Substr().
As I mentioned previously, I encourage you to get hold of "Design Patterns"
by Gamma et al. The way you illustrated the decision about which name format
to use, and creating the reader for it, was pretty clunky. There are
patterns described in this book that will give a much better approach to
this kind of thing (look for "factory").
But in this case, I don't think you need to go to all of the trouble you
did. It looks like the way to read a Name can be determined by an inspection
of the input Name line. If so, then you just need to implement that decision
logic in the property setter. Depending on your needs for getting the data
back out, you either implement multiple property setters (one for each
possible format) and let the caller decide, or you could remember the format
you discovered when it was initially set, and always mimic that format in
the property getter.
Tangential anecdote:
I live in New Jersey, whose Motor Vehicle Department apparently uses a
system just like the legacy system you're dealing with. My driver's license
expired recently, and I had to get it renewed. New (knee-jerk stupid)
identification requirement say I've got to provide N different forms of ID
in order to do this, including my old expiring license.
The thing is, the DMV's computers can't hold my name ("Christopher S.
Wuestefeld"), so they abbreviated my license to "C. S. Wuestefeld". All my
other docs (passport, firearms ID card, Social Security card, etc.) are
correct. But since *their* single piece of ID is *wrong*, and thus
mismatched, they rejected me. They sent me home, saying that the supposed
disproof of my old license outweighed my other docs, even the passport.
I dug up my birth certificate and went back a week later (for some reason,
the birth certificate is the ultimate ID, trumping everything else). This
was good enough for them to issue me a new license.
The name on the new license is "C. S. Wuestefeld". I protested that this
will cause the same problems in X years when I have to renew again. They
deny this, and say that it'll be OK. But I can't see how, since once again,
my expiring license will bear a name that differs from my passport, etc.
This was a headache for me, but it's going to be worse for my officemate.
He's also a Christopher, but his name no longer matches his birth
certificate (he was born "Chr!s Doody", and later changed it to "Chr!s
Dawson" -- what would you do?). So even that won't get him past their rules.
I suppose he'll have to get some kind of court documents.
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
