Structure as object property

[JSheble]

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

 

[Marina]

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]

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

 

[Marina]

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]

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

 

[Bruce Wood]

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.

 

[Marina]

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.