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

  • Thread starter Thread starter Tony Johansson
  • Start date Start date
T

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
 
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 ?
Click to expand...
What if the customer has multiple addresses?

// Anders
 
What if the customer has multiple addresses?
Click to expand...

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.
 
Exactly. If you want to store both a home address and a work address, I
think a separate address class is an excellent idea
Click to expand...

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...
 
What if the customer has multiple addresses?
Click to expand...

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
 
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...
Click to expand...

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
 
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 ?
Click to expand...

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
 
Back
Top