I've build an Address class in a "Util" namespace. I'm referencing that
namespace in another object which needs address data (call it "Agent").

It works fine, but when I access the Agent's address in code it looks like:

agent.Address.address1
agent.Address.city
....

What I'm looking for is a way to build a utility class that I can plug into
my Agent class so that the syntax is:

agent.address1
agent.city
....

Any pointers?

--
Message posted via http://www.dotnetmonster.com

Well you are talking about namespaces, classes and members.. namespaces are
ONLY used to organize where classes are, logically - to a developer. A
namespace is not anything other than a grouping tool.

A "class" is really what does the work. Think of a class like a blueprint to
a house, it isn't a house, it's just the instructions on how to build a
house. So you need to create an instance of a class (i.e. build a house) for
it to exist.

So from anywhere in your program, you should be able to do:

Util.Address objAgent = new Util.Address();

objAgent.address1 = "po box 1234";
objAgent.city = "sometown";


Is this what you meant?


"Walter Riggs via DotNetMonster.com" <(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...
> I've build an Address class in a "Util" namespace. I'm referencing that
> namespace in another object which needs address data (call it "Agent").
>
> It works fine, but when I access the Agent's address in code it looks
> like:
>
> agent.Address.address1
> agent.Address.city
> ...
>
> What I'm looking for is a way to build a utility class that I can plug
> into
> my Agent class so that the syntax is:
>
> agent.address1
> agent.city
> ...
>
> Any pointers?
>
> --
> Message posted via http://www.dotnetmonster.com

First off, I should point out that other programmers will be used to
seeing the first notation. The idea that an Agent has an Address, and
that Address has other components, is a familiar idiom. The second
idiom, that an Agent directly has components such as City and
AddressLine1 will strike others as strange.

That said, the only way you can accomplish what you want goes something
like this.

Create an IAddress interface that declares the "public face" of your
address class.

Have Address implement IAddress.

Have Agent contain an Address, but also implement IAddress. Every
IAddress property in Agent will then be coded like this:

public class Agent : IAddress
{
private Address theAddr;
...
public string City
{
get { return this.theAddr.City; }
}
}

and so on. No, there is no way of getting around having to code all of
those properties.

If I were you I would just make an Address property and leave it at
that... except in one situation.

The situation in which having an Address property alone is a bad idea
is if your Address class has mutable properties (get and set), but you
don't want to allow callers to change the Address of an Agent. In this
situation, if you expose Address directly through a property, you can't
control what callers can do with the properties of that Address, so if
you want to lock it down you have to expose the properties directly in
Agent.

That is a good reason why you shouldn't make setters for properties
unless there's a pressing reason to do so. I would much rather make
Address immutable (only getters, no setters). Then you can control
access to it in whatever classes have an Address. All that this means
is that you can't say:

myAgent.Address.City = "Baltimore";

you must instead say:

myAgent.Address = new Address(myAgent.Address, "Baltimore");

or something like that. Take a look at how the Font class works for an
example.

Again, it all depends upon what you want to achieve.

When you put it like this, "that an Agent directly has components such as
City and AddressLine1 will strike others as strange." I believe I'll leave
it like it is.

Thanks guys.

--
Message posted via http://www.dotnetmonster.com

Just be careful to take reference semantics into consideration. What I
mean by that is that if you end up with two Agents sharing a single
Address instance, then changing the address of one agent will change it
for the other as well. For example:

Address aPlace = new Address("#102 - 5555 Main Street", "Anytown",
"CA", "90210", "USA");
Agent agent1 = new Agent(..., aPlace, ...);
Agent agent2 = new Agent(..., aPlace, ...);
agent1.Address.City = "Othertown";

will change the address for both agents, because they share an address
object.

There are various ways to control this behaviour, from always cloning
an Address object in the constructor and whever it's set, to simply
allowing the behaviour to stand ("if both agents are in the same office
then changing the address of one _should_ change the address of the
other") and requiring your application programmers to move one agent to
another town while leaving the other where he/she is like this:

agent1.Address = new Address(...);

or, as I said, making Address immutable so that the _only_ way to
change an address of an agent is the foregoing. (So, you can look at
properties of address like this: agent1.Address.City, but you can't
change them.)

There's nothing wrong with having two agents pointing to the same
address instance... you just have to keep keep your object model (in
your head and on paper) drawn to indicate that that is what is
happening, and not lapse into the idea that every agent's Address is
independent of every other one.

Or, as I said, you can clone, or make immutable Addresses, and then
every agent really does have their own Address for all intents and
purposes.