471,350 Members | 1,873 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,350 software developers and data experts.

Structure as object property

Are there any reasons why I shouldn't or couldn't use a structure as a
property in a class? Specifically since structures are value types and
objects are reference types?

I have a Shipping object that has 4 different types of addresses.
Initially, I created 4 instances of an Address object, but seem
inefficient to me since the Address itslef doesn't really have (or need)
and methods... I was thinking a structure would be more efficient, but
thought that the different types (reference v.s. value) might cause a
problem when passing the object around...

I could also use some help in acessibility or scope. I don't want the
user of my object to create an instance of the Address class (structure?)
(as well as a few other objects), but they do need to access pieces of a
created Address.

Hmmm, I'm not sure I explained that well...

I do want the user of the class to be able to do this:

oShipment.ShipTo.Address1 = "blah blah blah"

But I don't want them to be able to do this:

oAddress = new Address();
oAddress.Address1 = "blah blah blah"

What's the best way to accomplish this?

Thanx!
Joe

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 14 '05 #1
6 1297
As long as the class initializes the private Address object exposed by the
ShipTo property, the user will still be able to say oShipment.ShipTo.Address
= "whatever".

"JSheble" <js***********@logicor.com> wrote in message
news:op***************@joelaptop.logicorphx2.com.. .
Are there any reasons why I shouldn't or couldn't use a structure as a
property in a class? Specifically since structures are value types and
objects are reference types?

I have a Shipping object that has 4 different types of addresses.
Initially, I created 4 instances of an Address object, but seem
inefficient to me since the Address itslef doesn't really have (or need)
and methods... I was thinking a structure would be more efficient, but
thought that the different types (reference v.s. value) might cause a
problem when passing the object around...

I could also use some help in acessibility or scope. I don't want the
user of my object to create an instance of the Address class (structure?)
(as well as a few other objects), but they do need to access pieces of a
created Address.

Hmmm, I'm not sure I explained that well...

I do want the user of the class to be able to do this:

oShipment.ShipTo.Address1 = "blah blah blah"

But I don't want them to be able to do this:

oAddress = new Address();
oAddress.Address1 = "blah blah blah"

What's the best way to accomplish this?

Thanx!
Joe

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Dec 14 '05 #2
So I could define my Address structure as Private with private fields? Or
Internal?

On Wed, 14 Dec 2005 11:03:00 -0700, Marina <so*****@nospam.com> wrote:
As long as the class initializes the private Address object exposed by
the
ShipTo property, the user will still be able to say
oShipment.ShipTo.Address
= "whatever".

"JSheble" <js***********@logicor.com> wrote in message
news:op***************@joelaptop.logicorphx2.com.. .
Are there any reasons why I shouldn't or couldn't use a structure as a
property in a class? Specifically since structures are value types and
objects are reference types?

I have a Shipping object that has 4 different types of addresses.
Initially, I created 4 instances of an Address object, but seem
inefficient to me since the Address itslef doesn't really have (or need)
and methods... I was thinking a structure would be more efficient, but
thought that the different types (reference v.s. value) might cause a
problem when passing the object around...

I could also use some help in acessibility or scope. I don't want the
user of my object to create an instance of the Address class
(structure?)
(as well as a few other objects), but they do need to access pieces of a
created Address.

Hmmm, I'm not sure I explained that well...

I do want the user of the class to be able to do this:

oShipment.ShipTo.Address1 = "blah blah blah"

But I don't want them to be able to do this:

oAddress = new Address();
oAddress.Address1 = "blah blah blah"

What's the best way to accomplish this?

Thanx!
Joe

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 14 '05 #3
Huh?

I was talking about making it a class, and having the class that contains
properties of that type be responsible for making sure there is always a
valid instance being returned by the property.

"JSheble" <js***********@logicor.com> wrote in message
news:op***************@joelaptop.logicorphx2.com.. .
So I could define my Address structure as Private with private fields? Or
Internal?

On Wed, 14 Dec 2005 11:03:00 -0700, Marina <so*****@nospam.com> wrote:
As long as the class initializes the private Address object exposed by
the
ShipTo property, the user will still be able to say
oShipment.ShipTo.Address
= "whatever".

"JSheble" <js***********@logicor.com> wrote in message
news:op***************@joelaptop.logicorphx2.com.. .
Are there any reasons why I shouldn't or couldn't use a structure as a
property in a class? Specifically since structures are value types and
objects are reference types?

I have a Shipping object that has 4 different types of addresses.
Initially, I created 4 instances of an Address object, but seem
inefficient to me since the Address itslef doesn't really have (or need)
and methods... I was thinking a structure would be more efficient, but
thought that the different types (reference v.s. value) might cause a
problem when passing the object around...

I could also use some help in acessibility or scope. I don't want the
user of my object to create an instance of the Address class
(structure?)
(as well as a few other objects), but they do need to access pieces of a
created Address.

Hmmm, I'm not sure I explained that well...

I do want the user of the class to be able to do this:

oShipment.ShipTo.Address1 = "blah blah blah"

But I don't want them to be able to do this:

oAddress = new Address();
oAddress.Address1 = "blah blah blah"

What's the best way to accomplish this?

Thanx!
Joe

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Dec 14 '05 #4
Ahhh... I was talking about making it a structure first, then asked how to
keep users of my object from instantiating an instance of it, but still be
able to access it via a public property of the containing object...

On Wed, 14 Dec 2005 11:22:01 -0700, Marina <so*****@nospam.com> wrote:
Huh?

I was talking about making it a class, and having the class that contains
properties of that type be responsible for making sure there is always a
valid instance being returned by the property.

"JSheble" <js***********@logicor.com> wrote in message
news:op***************@joelaptop.logicorphx2.com.. .
So I could define my Address structure as Private with private fields?
Or
Internal?

On Wed, 14 Dec 2005 11:03:00 -0700, Marina <so*****@nospam.com> wrote:
As long as the class initializes the private Address object exposed by
the
ShipTo property, the user will still be able to say
oShipment.ShipTo.Address
= "whatever".

"JSheble" <js***********@logicor.com> wrote in message
news:op***************@joelaptop.logicorphx2.com.. .
Are there any reasons why I shouldn't or couldn't use a structure as a
property in a class? Specifically since structures are value types
and
objects are reference types?

I have a Shipping object that has 4 different types of addresses.
Initially, I created 4 instances of an Address object, but seem
inefficient to me since the Address itslef doesn't really have (or
need)
and methods... I was thinking a structure would be more efficient,
but
thought that the different types (reference v.s. value) might cause a
problem when passing the object around...

I could also use some help in acessibility or scope. I don't want the
user of my object to create an instance of the Address class
(structure?)
(as well as a few other objects), but they do need to access pieces
of a
created Address.

Hmmm, I'm not sure I explained that well...

I do want the user of the class to be able to do this:

oShipment.ShipTo.Address1 = "blah blah blah"

But I don't want them to be able to do this:

oAddress = new Address();
oAddress.Address1 = "blah blah blah"

What's the best way to accomplish this?

Thanx!
Joe

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Dec 14 '05 #5
Your struct must be declared at the same accessibility level as the
property that returns it. Otherwise the compiler will complain that you
are exposing a (for example) public property whose return type is (for
example) internal, and so your clients could never use the property.

However, you _could_ make all of the constructors for the struct
internal, meaning that no client code could ever instantiate a (valid)
Address. (Note, however, that client code _could declare_ an Address,
which would create the Address with all fields null / zero. They just
couldn't initialize those fields to anything meaningful.) This works
better with classes, by the way, for which making all of the
constructors internal / protected / private effectively means that the
outside world can _use_ objects of that class but could never _create_
one.

However, aside from all of this I think that you want Address to be a
class, not a struct.
I created 4 instances of an Address object, but seem
inefficient to me since the Address itslef doesn't really have (or need)
any methods...
That's not really a good reason to make something a struct. Make it a
struct if it is logically a value, like an int, a double, or a
DateTime, or if you're doing massive numbers of calculations with it
and allocating / garbage collecting transient instances of it would
create performance problems (e.g. Point, Rectangle). Four addresses
doesn't really fit into that category, IMHO.
I was thinking a structure would be more efficient, but
thought that the different types (reference v.s. value) might cause a
problem when passing the object around...


Yes, it will cause problems, particularly if your Address object
exposes mutable properties (with "set" methods). It's not the end of
the world, but I think that the extra thinking you'll have to do in
order to use an Address struct successfully will more than outweigh any
minor efficiency improvements that might result. Just my opinion.

Dec 14 '05 #6
Right, but I think your concerns with passing around structures are valid.
As soon as you have a second variable assigned to a structure instance, it
actually gets a copy of it, and from then on there are 2 different instances
of the structure. What you change in one does not effect the other - this is
not desired behavior for most cases.

So you should stick with the class, and you can still access everything in
it via a property and not have to worry about the end consumer instantiating
the property, because the class defining the property should be the one to
do it.

"JSheble" <js***********@logicor.com> wrote in message
news:op***************@joelaptop.logicorphx2.com.. .
Ahhh... I was talking about making it a structure first, then asked how to
keep users of my object from instantiating an instance of it, but still be
able to access it via a public property of the containing object...

On Wed, 14 Dec 2005 11:22:01 -0700, Marina <so*****@nospam.com> wrote:
Huh?

I was talking about making it a class, and having the class that contains
properties of that type be responsible for making sure there is always a
valid instance being returned by the property.

"JSheble" <js***********@logicor.com> wrote in message
news:op***************@joelaptop.logicorphx2.com.. .
So I could define my Address structure as Private with private fields?
Or
Internal?

On Wed, 14 Dec 2005 11:03:00 -0700, Marina <so*****@nospam.com> wrote:

As long as the class initializes the private Address object exposed by
the
ShipTo property, the user will still be able to say
oShipment.ShipTo.Address
= "whatever".

"JSheble" <js***********@logicor.com> wrote in message
news:op***************@joelaptop.logicorphx2.com.. .
> Are there any reasons why I shouldn't or couldn't use a structure as a
> property in a class? Specifically since structures are value types
> and
> objects are reference types?
>
> I have a Shipping object that has 4 different types of addresses.
> Initially, I created 4 instances of an Address object, but seem
> inefficient to me since the Address itslef doesn't really have (or
> need)
> and methods... I was thinking a structure would be more efficient,
> but
> thought that the different types (reference v.s. value) might cause a
> problem when passing the object around...
>
> I could also use some help in acessibility or scope. I don't want the
> user of my object to create an instance of the Address class
> (structure?)
> (as well as a few other objects), but they do need to access pieces
> of a
> created Address.
>
> Hmmm, I'm not sure I explained that well...
>
> I do want the user of the class to be able to do this:
>
> oShipment.ShipTo.Address1 = "blah blah blah"
>
> But I don't want them to be able to do this:
>
> oAddress = new Address();
> oAddress.Address1 = "blah blah blah"
>
> What's the best way to accomplish this?
>
> Thanx!
> Joe
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Dec 14 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by dan heskett | last post: by
4 posts views Thread by John | last post: by
4 posts views Thread by Alexander Adam | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.