OK... let's try this again.
I'm curious -- why did you advise that?
For two reasons.
First, remember that structs are value types in .NET. That means that,
like an int or a double, they are copied on every assignment, copied
onto the stack to pass as arguments, and copied onto the stack when
returned as method or property results. This makes perfect sense for
ints, doubles, and even DateTimes: I have never run into a situation in
which I want to change every single variable in my program that holds
the value 5 to now hold the value 7. Every variable has its own copy of
the value, and changing one variable doesn't affect any other one. In
fact, for most values "changing the value" makes no sense at all: to
change what a variable holds you assign a new value.
Is this the kind of behaviour that is appropriate for something like a
"Branch"? Branches have identities: you can sensibly talk about "Branch
15" in our company. When I change some quality of Branch 15, it's
perfectly reasonable to assume (or desire) that every other variable
that holds (a reference to) Branch 15 will see that change as well. Do
I want a Branch to be copied on every assignment, copied onto the stack
for method calls, and copied onto the stack for method returns? Do I
want a system in which it's impossible, or near-impossible to have a
change to a Branch 15 stored in one variable affect the Branch 15
that's held by other variables in other parts of my system? I don't
think so.
..NET structs are tremendously useful in rare cases. In those
particular, peculiar situations they are indispensible. In almost every
other situation they are unnecessary. I see nothing in this problem
that says that the OP's Branch type is one of those rare circumstances
in which value semantics are useful. As Jon said, classes (that is,
reference semantics) should be the default choice. structs (value
semantics) should be employed only when there's a compelling reason to
do so. I see no such reason here.
However, I said that there were two reasons.
The second is that the OP self-identified as a newbie. IMHO,
programmers new to .NET should steer far clear of structs. They are
very, very unlikely to run into one of those rare circumstances in
which value semantics are a good idea. They are much, much more likely
to misapply structs and then wonder why their programs act strangely.
At best this will result in some confusion followed by a decision to
use classes instead; at worst this will result in the incorrect
conclusion that C# makes no sense and therefore sucks.
Take the OP's problem, for example. Göran suggested using an ArrayList
to hold the Branches. This is the simplest design, especially for a new
programmer to follow. Imagine the OP's confusion when they design their
Branch like this:
public struct Branch
{
private int _id;
private ArrayList _itemList;
public Branch(int branchId)
{
this._id = branchId;
this._itemList = new ArrayList();
}
public AddItem(string item1, string item2, string item3)
{
string[] items = new string[3];
items[0] = item1;
items[1] = item2;
items[2] = item3;
}
}
Again, a simple, straightforward design. With one catch: imagine the
OP's surprise when this doesn't work:
public static void Main()
{
ArrayList branchList = new ArrayList();
... some sort of loop to read branches here ...
Branch aBranch = new Branch(id);
branchList.Add(aBranch);
... some sort of loop to read items here ...
aBranch.AddItems(item1, item2, item3);
}
Imagine the consternation when the OP discovers that all of the
branches in the array list have zero items attached to them. Why? What
happened? What kind of stupid language is this, anyway?
Change "public struct Branch" to "public class Branch" and it works.
Experienced .NET programmers with a firm grasp of value semantics
versus reference semantics will, of course, be able to figure out why.
Newbie programmers will, generally speaking, not... not without alot of
pain and research.
If you want to read more about struct versus class, see the following
threads:
http://groups.google.com/group/micr...ges.csharp/browse_frm/thread/a13bcc64b8438f65
http://groups.google.com/group/micr...ges.csharp/browse_frm/thread/e7862a7d7d6a914c
