Accessing "complex types" in an object property

[Andy B.]

I have the following objects layed out in code. I keep them simple here for
sake of the list (the actual objects are around 300 lines of code each).

'Define an address object.
namespace Events
private class Address
'Fields
dim Street as string
dim Line2 as string
dim City as string
dim State as TeritoryCode
dim Country as CountryCode
dim ZipCode as string

'Properties for the above fields. Since the address object is nothing more
than a container for data, the property definitions are skipped here to make
things simple.

'Constructers
Address(...)
end function
end class

'Define a Venue
private class Venue
'Fields
private Name as string
Private Address as Address
private Type as string

'Properties for above fields.
public property Name() as string
get
return Name
end get
set(ByVal Value as string)
Name = Value
end set
end property

public property Address() as Address
get
return Address
end get
set(ByVal Value as Address)
Address=Value
End set
end property
public property Type() as string
get
return Type
end get
set(ByVal Value as string)
Type = value
end set
end property
end class
end namespace
What I want to know, is how do you access the Address property values in the
Venue.Address property. I'm thinking something like:

dim Venue1 as new Venue()
dim AddressForVenue1 as new Address()

AddressForVenue1.Street="123 StreetName"
AddressForVenue1.Line2=string.empty
AddressForVenue1.City="Detroit"
AddressForVenue1.State = TerritoryCode.MI
AddressForVenue1.Country = CountryCode.USA
AddressForVenue1.ZipCode = "12345"

Venue1.Address = AddressForVenue1
'Or can I do it this way instead?
Venue1.Address.Street = "123 StreetName"
Venue1.Address.Line2 = string.empty
Venue1.Address.City="Detroit"
'... and so on?

What way is better and more practicle to do?

 

[OmegaSquared]

Hello, Andy,

Which technique is "better" may depend on factors that are not shown in the
abbreviated sample. For example, if the Address objects are usually created
or edited elsewhere (i.e. in a separate form or class), then the first
approach (i.e. setting/replacing the entire Address object) seems to make the
most sense. But if only properties of the Address object are ever accessed
then the second method might be superior. (In this case the Address property
could be made ReadOnly, provided that the local Address object is created
during Venue's construction.) The second method may also have advantages in
cases where other objects are holding references to a Venue's Address. (If
the Venue's Address object is changed, these references will (probably) be
invalid and need to be updated.)

Cheers,
Randy

 

[Andy B.]

Hello, Andy,

Which technique is "better" may depend on factors that are not shown in
the
abbreviated sample. For example, if the Address objects are usually
created
or edited elsewhere (i.e. in a separate form or class), then the first
approach (i.e. setting/replacing the entire Address object) seems to make
the
most sense. But if only properties of the Address object are ever
accessed
then the second method might be superior. (In this case the Address
property
could be made ReadOnly, provided that the local Address object is created
during Venue's construction.) The second method may also have advantages
in
cases where other objects are holding references to a Venue's Address.
(If
the Venue's Address object is changed, these references will (probably) be
invalid and need to be updated.)

Cheers,
Randy

The only time a venue's address can be modified is when the user is editing
the venue itself or creating the venue for the very first time. Otherwise
anything else has to have readonly access to the address.

 

[OmegaSquared]

Hello, Andy,

In that case, the second method seems to be preferred. As mentioned, I
would probably go further and make the Address property ReadOnly, as in:

'Define a Venue
private class Venue
'Fields
...
Private _Address as New Address
...
'Properties for above fields.
...
public ReadOnly property Address() as Address
get
return _Address
end get
end property

Of course this doesn't make the properties of the contained Address object
readonly. It merely prevents replacing the Address object itself. If you
need its properties to be ReadOnly in some cases, you may wish to create one
set of read/writable properties that have scope limited to Venue and another
set of ReadOnly properties that have wider scope.

Cheers,
Randy

 

[Andy B.]

If Vneue1.Address.Street is read only, how would I change it other than
making a totally different Address object?
explain how this works...

 

[OmegaSquared]

Hi, Andy,

If Venue1.Address.Street were ReadOnly you wouldn't be able to change it.
But you could create a second property (for example "StreetX") that was not
ReadOnly. If the scope of StreetX is Friend and the Scope of Street is
Public then only code within the same project as Address would be able to
update the common value that they both return. But the ReadOnly property
Street would be available to code in any project. (The trick then is to
structure the projects in your solution so that only those objects that need
the Read/Write access have it.)

More explicitly, you could define these Properties like:

Public ReadOnly Property Street() As String
Get
Return _Street
End Get
End Property

Friend Property StreetX() As String
Get
Return _Street
End Get
Set(ByVal NewStreet as String)
_Street = NewStreet
End Set
End Property

Then, as long as your Venue class and your Address class are in the same
project, Venue can update the Street property (by updating StreetX).

Cheers,
Randy

 

[Andy B.]

Is there a way to narrow this friend thing down to a smaller scope? Say a
namespace? The issue is that everything at this point is in the same project
so friend wouldn't make any difference. Is there any real world examples for
this way of doing things as well?

 

[OmegaSquared]

Hello, Andy,

Re: "Is there a way to narrow this friend thing down to a smaller scope?"

Not that I'm aware of. I guess the option is to restructure your solution
into more than one project. How much effort is required for this will depend
on the current scope of the interfaces between your objects. It can end up
being a bit of a chore, so ultimately you have to decide if the gain is worth
the pain.

Re: "Is there any real world examples..."

Undoubtedly. But... I'm not sure that I exist within the "real world".
Unfortunately, I can only provide "mocked up" examples like I've shown.
Anything else within my reach is proprietary.

Cheers,
Randy