format display of an object

[Peter]

Hi

I have an "Address" object, which has properties for a person's
lastname, firstname, street name, house number, house letter etc.

I need to display the data from this address object in different
formats - sometimes I need to display "Highstreet 64A", and other times
"64A Highstreet" for example.

Is there a good method for displaying different formats of a custom
object?

I have seen IFormatProvider and ICustomFormatter, but I haven't yet
ascertained if this is the way to go...

Thanks for any pointers,
Peter

--

 

[Peter Morris]

First I'd recommend not having LastName, FirstName on an address. Addresses
typically don't have those You might want to use GivenName / FamilyName
too, as in some parts of the world their first name is their family name and
their last name is the individual name given by their parents.

Now onto the question. Does the address format change depending on the
installation, on user options, or on a per-object basis depending on data
(such as the country the address is within)?

 

[Peter]

First I'd recommend not having LastName, FirstName on an address.
Addresses typically don't have those You might want to use
GivenName / FamilyName too, as in some parts of the world their first
name is their family name and their last name is the individual name
given by their parents.

Now onto the question. Does the address format change depending on
the installation, on user options, or on a per-object basis depending
on data (such as the country the address is within)?

Hi, thanks for the reply.

The "Address" object contains all the contact info relevant for a
person in our application. That's why there is all sorts of info like
name, telephone number, email address, street address.... One could
argue that "Address" is therefore a bad name for this class, but that's
the way it is...

The various data in the Address needs to be displayed slightly
differently depending on configuration at various installations. I was
thinking that there could be some sort of configuration, which in some
way indicated how the address data should be formatted as a string.

Does it make a difference if it is an "installation" or "user options"
or "per-object" variation in format?


Thanks,
Peter

--

 

[Peter Morris]

argue that "Address" is therefore a bad name for this class, but that's

the way it is...

hehehe. That reminds me of a story about some monkeys in a cage:
http://freekvermeulen.blogspot.com/2008/08/monkey-story-experiment-involved-5.html

The various data in the Address needs to be displayed slightly
differently depending on configuration at various installations.

I'd probably just have a static class responsible for formatting the string
which the "Address" uses. You could specify a fully qualified class name in
your app.config of a class that implements a specific interface

public interface IAddressFormatter
{
string GetDisplayString(Address address);
}

The static class could load the specified type and use it to return the
format you specify.

Does it make a difference if it is an "installation" or "user options"
or "per-object" variation in format?

Installation = app.config
User options = same as above except it needs to be switchable at runtime and
keyed in a table
Per - object = uses data from the DB (such as Address.Country) to identify
the format

 

[Jeff Johnson]

The "Address" object contains all the contact info relevant for a
person in our application. That's why there is all sorts of info like
name, telephone number, email address, street address.... One could
argue that "Address" is therefore a bad name for this class, but that's
the way it is...

And argued successfully. You provided an infinitely better name in the
paragraph above: ContactInfo. Oh well. I assume it's too late to
refactor...?

The various data in the Address needs to be displayed slightly
differently depending on configuration at various installations. I was
thinking that there could be some sort of configuration, which in some
way indicated how the address data should be formatted as a string.

As far as the implementation goes, why not provide an overload of ToString()
which accepts a string with a "formatting code." It doesn't have to be as
complex as, say, what a DateTime can handle, but could simply be "U" for US
addresses, "C" for Canada, "E" for Europe (although I doubt every country in
Europe uses the same address scheme, but what do I know?) and so on.

 

[Peter]

And argued successfully. You provided an infinitely better name in
the paragraph above: ContactInfo. Oh well. I assume it's too late to
refactor...?

It's an existing class - returned from an existing service. The orginal
version only contained strictly address information. Then came phone
number, name, email etc etc, which were simply tacked onto the existing
class.

As far as the implementation goes, why not provide an overload of
ToString() which accepts a string with a "formatting code." It
doesn't have to be as complex as, say, what a DateTime can handle,
but could simply be "U" for US addresses, "C" for Canada, "E" for
Europe (although I doubt every country in Europe uses the same
address scheme, but what do I know?) and so on.

I can't add a ToString to the class (well I guess I could add an
extension method? Not that I have much experience with them). But I've
made a couple of "IAddressFormatter" classes - which each have their
own specialised way of formatting the address as a string. The caller
needs to instantiate the desired formatter and pass the Address object
to the formatter which spits out the correct string. Actually I've made
a "helper" class which can instantiate the desired formatter from
configuration, and call the format method, and return the string.

Thanks for the help!

/Peter

 

[Jeff Johnson]

It's an existing class - returned from an existing service. [...]
I can't add a ToString to the class (well I guess I could add an
extension method? Not that I have much experience with them).

Aha. Your original post said "I have an object," and didn't indicate that
you weren't in control of the object's source. Now I see your problem, and
that my suggestion doesn't help you.

See how important details are?