Assume I create a class Customer is it advice to have a separate class to store addresses

[Tony Johansson]

Hello!

I read a program that created a Customer class with some basic information
such as name, birthdate telephone and so on and
then used a separate Address class to store the address information in the
Customer class.

I just wonder it that a good approach to create a separate class just for
that address to store the address object in the Customer. I would instead
store the primitive fields such as zip code,street name and city and thing
like that directly
in the customer class without using any separate class for this.

Give me a comment about what you opinion is ?

//Tony

 

[Anders Eriksson]

Hello!

I read a program that created a Customer class with some basic information
such as name, birthdate telephone and so on and
then used a separate Address class to store the address information in the
Customer class.

I just wonder it that a good approach to create a separate class just for
that address to store the address object in the Customer. I would instead
store the primitive fields such as zip code,street name and city and thing
like that directly
in the customer class without using any separate class for this.

Give me a comment about what you opinion is ?

What if the customer has multiple addresses?

// Anders

 

[Jeff Johnson]

What if the customer has multiple addresses?

Exactly. If you want to store both a home address and a work address, I
think a separate address class is an excellent idea. If, however, your
business rules dictate that you will only ever store a single address for a
customer then I say put it in the customer class.

 

[Jeff Gaines]

Exactly. If you want to store both a home address and a work address, I
think a separate address class is an excellent idea

Building on that you may need to know an address at a certain date so an
address class with a From and To field may be appropriate, as well as a
flag to indicate home address, business address, club address etc...

 

[Arne Vajhøj]

What if the customer has multiple addresses?

That would be a good reason to have a class.

public class Customer
{
private Address home;
private Address work;

or:

public class Customer
{
private IList<Address> addrs;

Arne

 

[Arne Vajhøj]

Building on that you may need to know an address at a certain date so an
address class with a From and To field may be appropriate, as well as a
flag to indicate home address, business address, club address etc...

Good point about the historical aspect.

I am not sure that from and to are really attributes
of Address though.

Maybe:

public enum AddressType { HOME, WORK, OTHER }

public class Address
{

public class Location
{
private DateTime from;
private DateTime to;
private AddressType typ;
private Address addr;

public class Customer
{
private IList<Location> loc;

There are many ways to model this.

Arne

 

[Arne Vajhøj]

I read a program that created a Customer class with some basic information
such as name, birthdate telephone and so on and
then used a separate Address class to store the address information in the
Customer class.

I just wonder it that a good approach to create a separate class just for
that address to store the address object in the Customer. I would instead
store the primitive fields such as zip code,street name and city and thing
like that directly
in the customer class without using any separate class for this.

Give me a comment about what you opinion is ?

It is definitely possible to argue that an address is
a separate entity.

But whether it is relevant to create a class for it depends on whether
you can reuse the concept in other places than the Customer class.

For a large real world app that sounds very likely to be the case.

For concrete ideas, see some of my replies to other posts in
this thread.

Arne