Collection vs. List vs. ??

  • Thread starter Thread starter Jon Davis
  • Start date Start date
J

Jon Davis

I'm managing "collections" / "lists" (??) of objects that are internally
bound by an XML document, but I do NOT intend to offer an IEnumerator
interface.

For instance, with a root XML document, I might have:

<employees>
<employee><name>bob</name></employee>
<employee><name>carl</name></employee>
<employees>

... and I might have a C# class as such:

public class Employee {
public Employee(XmlNode employeeNode) {
InnerEmployeeNode = employeeNode;
}
private XmlNode InnerEmployeeNode;

public string Name {
get {
return InnerEmployeeNode.SelectSingleNode("name").InnerText;
}
}
}

.... and so now I have a "list" or "collection" of sorts as such:

public class EmployeeList {
public EmployeeList (XmlNode employeesNode) {
InnerEmployeesNode = employeesNode;
}
private XmlNode InnerEmployeesNode;
public Employee this[string name] {
get {
XmlNodeList employeeNodes =
InnerEmployeesNode.SelectNodes("employee");
foreach (XmlNode node in EmployeeNodes) {
if (node.SelectSingleNode("name") == name) {
return new Employee(node);
}
}
return null;
}
}
}

So now my question is, what should I call this list type?
"EmployeeCollection"? "EmployeeList"? "EmployeeArray" in such a way that it
is not confusing. I myself am confused.

Thanks,
Jon
 
Why bother making an employee list at all ?

You've got a clear class here, Employee, that contains the name member
variable.

Instead of thinking of EmployeeList as an instance of a class, think
of listing employees as a static (global) method of Employee.

That is to say, the static gets called with the XmlNode, gobbles up
and instantiates the employees records, instantiating employees as it
does so (poof you're an employee), and then returns a Employee[] (or
ArrayList of.;. (or even Hashtable[empname,empInstance].

If it turns out that you're _only_ creating employees within the
EmployeeList logic, then you can even go further, by making the
Employee constructor private. You call a public static
Employee.EmployeeListReader(XmlNode someNode) and it returns a
collection to you.

HTH

MMM
 
No, in this[int index] I'm returning an Employee object, and I intend to
make the XML binding transparent to users of this assembly.

Jon


Jay Glynn said:
EmployeeNodeList since you are returning XmlNode.

Jon Davis said:
I'm managing "collections" / "lists" (??) of objects that are internally
bound by an XML document, but I do NOT intend to offer an IEnumerator
interface.

For instance, with a root XML document, I might have:

<employees>
<employee><name>bob</name></employee>
<employee><name>carl</name></employee>
<employees>

.. and I might have a C# class as such:

public class Employee {
public Employee(XmlNode employeeNode) {
InnerEmployeeNode = employeeNode;
}
private XmlNode InnerEmployeeNode;

public string Name {
get {
return InnerEmployeeNode.SelectSingleNode("name").InnerText;
}
}
}

... and so now I have a "list" or "collection" of sorts as such:

public class EmployeeList {
public EmployeeList (XmlNode employeesNode) {
InnerEmployeesNode = employeesNode;
}
private XmlNode InnerEmployeesNode;
public Employee this[string name] {
get {
XmlNodeList employeeNodes =
InnerEmployeesNode.SelectNodes("employee");
foreach (XmlNode node in EmployeeNodes) {
if (node.SelectSingleNode("name") == name) {
return new Employee(node);
}
}
return null;
}
}
}

So now my question is, what should I call this list type?
"EmployeeCollection"? "EmployeeList"? "EmployeeArray" in such a way that it
is not confusing. I myself am confused.

Thanks,
Jon
Click to expand...
Click to expand...
 
Why bother making an employee list at all ?
You've got a clear class here, Employee, that contains the name member
variable.
Instead of thinking of EmployeeList as an instance of a class, think
of listing employees as a static (global) method of Employee.
Click to expand...

Why is irrelevant. The code sample is not what I'm using. And I intend to
make the XML binding transparent to the users of my assembly.

Jon


Mark Mullin said:
Why bother making an employee list at all ?

You've got a clear class here, Employee, that contains the name member
variable.

Instead of thinking of EmployeeList as an instance of a class, think
of listing employees as a static (global) method of Employee.

That is to say, the static gets called with the XmlNode, gobbles up
and instantiates the employees records, instantiating employees as it
does so (poof you're an employee), and then returns a Employee[] (or
ArrayList of.;. (or even Hashtable[empname,empInstance].

If it turns out that you're _only_ creating employees within the
EmployeeList logic, then you can even go further, by making the
Employee constructor private. You call a public static
Employee.EmployeeListReader(XmlNode someNode) and it returns a
collection to you.

HTH

MMM

"Jon Davis" <[email protected]> wrote in message
I'm managing "collections" / "lists" (??) of objects that are internally
bound by an XML document, but I do NOT intend to offer an IEnumerator
interface.
Click to expand...
Click to expand...
 
Why is Employee<listtype> not equivalent to Collection of Employee ?

If you're going to create employee<sometypeoflist>, what distinguishes
this list of employees from any other list beyond the contents of the
list? Is the list expected to perform operations on the set of
employees that cause it to be a specialization of an existing list
class ? If so, you may want to consider derivation from one of the
existing classes. What in your proposed architecture cares about a
set of employees as a tangible thing providing functionality distinct
from other sets of homogenous data ? Answers to those questions
should make the appropriate name leap out at you.

All that said, Employees might be perfectly fine, since you're trying
to have the name represent what it is, and you've indicated that the
nature of the list (list of XML nodes) ain't what it is.

Entia non sunt multiplicanda praeter necessitatem
 
What in your proposed architecture cares about a
set of employees as a tangible thing providing functionality distinct
from other sets of homogenous data ?
Click to expand...

None. I suppose I should ask in another way:

If I have a set of homogenous data that is indexed with this[...] and
nothing more (i.e. no IEnumerator), what is the base suffix for C# that is
considered legal in terms of standardization and readability? "-Collection"?
"-Set"?

Are you saying that the correct suffix is "-s"?
Why is Employee<listtype> not equivalent to Collection of Employee ?
Click to expand...

I could call it "collection of employee", but C# class names cannot be named
as such (with spaces) and it would break the conventions. So in translation
you're suggesting EmployeeCollection, but is it indeed a collection if it
does not implement IList, ICollection(??), and so on?

Jon
 
Why is Employee<listtype> not equivalent to Collection of Employee ?

Incidentally, if you mean why shouldn't I just use a generic collection, the
answer is that a generic collection does not bind to specific XML like I
intend for it to. Nor do I want users of my assembly to have to futz with
type casting from Object.

(Please don't suggest that I just read the XML and spit out a set of objects
and throw it into a container, that is NOT disciplined C# coding. I bind to
XML because if an object changes, I want the XML to change immediately. It
is thread-safe, it is instance-safe, and it thereby eliminates a heck of a
lot of hassles. XML synchronization is the product I am selling!
http://www.powerblog.net/ )

Jon


Jon Davis said:
What in your proposed architecture cares about a
set of employees as a tangible thing providing functionality distinct
from other sets of homogenous data ?
Click to expand...

None. I suppose I should ask in another way:

If I have a set of homogenous data that is indexed with this[...] and
nothing more (i.e. no IEnumerator), what is the base suffix for C# that is
considered legal in terms of standardization and readability? "-Collection"?
"-Set"?

Are you saying that the correct suffix is "-s"?
Why is Employee<listtype> not equivalent to Collection of Employee ?
Click to expand...

I could call it "collection of employee", but C# class names cannot be named
as such (with spaces) and it would break the conventions. So in translation
you're suggesting EmployeeCollection, but is it indeed a collection if it
does not implement IList, ICollection(??), and so on?

Jon


Mark Mullin said:
Why is Employee<listtype> not equivalent to Collection of Employee ?

If you're going to create employee<sometypeoflist>, what distinguishes
this list of employees from any other list beyond the contents of the
list? Is the list expected to perform operations on the set of
employees that cause it to be a specialization of an existing list
class ? If so, you may want to consider derivation from one of the
existing classes. What in your proposed architecture cares about a
set of employees as a tangible thing providing functionality distinct
from other sets of homogenous data ? Answers to those questions
should make the appropriate name leap out at you.

All that said, Employees might be perfectly fine, since you're trying
to have the name represent what it is, and you've indicated that the
nature of the list (list of XML nodes) ain't what it is.

Entia non sunt multiplicanda praeter necessitatem
Click to expand...
Click to expand...
 
Back
Top