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

On 2011-01-24 15:34, Tony Johansson wrote:
> 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

"Anders Eriksson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

>> 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?

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.

On 24/01/2011 in message <ihk6c2$8ab$(E-Mail Removed)> Jeff
Johnson wrote:

>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...

--
Jeff Gaines Wiltshire UK
There is absolutely no substitute for a genuine lack of preparation

On 24-01-2011 10:10, Anders Eriksson wrote:
> On 2011-01-24 15:34, Tony Johansson wrote:
>> 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?

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

On 24-01-2011 12:14, Jeff Gaines wrote:
> On 24/01/2011 in message <ihk6c2$8ab$(E-Mail Removed)> Jeff
> Johnson wrote:
>> 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...

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

On 24-01-2011 09:34, Tony Johansson wrote:
> 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