Structure as object property

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

JSheble - 14 Dec 2005 17:49 GMT

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

Signature

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

Reply to this Message

Marina - 14 Dec 2005 18:03 GMT

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

> 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
[quoted text clipped - 27 lines]
> Thanx!
> Joe

Reply to this Message

JSheble - 14 Dec 2005 18:13 GMT

So I could define my Address structure as Private with private fields? Or
Internal?

> As long as the class initializes the private Address object exposed by
> the
[quoted text clipped - 37 lines]
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Signature

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

Reply to this Message

Marina - 14 Dec 2005 18:22 GMT

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.

> So I could define my Address structure as Private with private fields? Or
> Internal?
[quoted text clipped - 40 lines]
>>> --
>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Reply to this Message

JSheble - 14 Dec 2005 18:45 GMT

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

> Huh?
>
[quoted text clipped - 54 lines]
>> --
>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Signature

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

Reply to this Message

Bruce Wood - 14 Dec 2005 19:02 GMT

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.

Reply to this Message

Marina - 14 Dec 2005 19:03 GMT

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.

> 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
[quoted text clipped - 58 lines]
>>> --
>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Reply to this Message

Structure as object property

Free Magazines