Is a lookup key a property?

Question

This is sparked by this where an OP did not want to add a string he was using for a key lookup because he did not consider it property of the class.

To me the fact you are using it a for a lookup means it is a property. To me anything you search on would be a legitimate property of the class.

Could a lookup key not be considered a property of the class?

Example

class MyClass 
{
     public string Description 
}

Dictionary<string, List<MyClass>>  MyClasss

Versus

class MyClassWithName 
{
     public string Description 
     public string Name
}

List<MyClassWithName>  MyClassesWithName

Yes lookup/search has gone from O(1) to O(n) but has MyClassWithName violated anything?

Answer 1

Both you and your friend are thinking far to abstract. It depends on the meaning and purpose of the objects and properties in question.

Say you fetch a list of entities from a database. To optimize lookup you create a dictionary which maps from the entity id to the entity. In this case the id would be both the key in the dictionary and a property on the object.

In another case you might count the frequency of words in a text by building a dictionary from word to an integer counter. In this case the key is not a property on the value.

So both cases are possible.

Answer 2

To me the fact you are using it a for a lookup means it is a property.

That's an inaccurate conclusion. One does not imply the other. If you look at the data through SQL colored glasses, then you are right -- the key is a property of a row. But that is not true in general.

To me anything you search on would be a legitimate property of the class.

Once again, that's true if you look from an SQL point of view but it is not true in general data model.

Could a lookup key not be considered a property of the class?

Yes.

Let me give you an example from a CAD point of view. A Part can have various properties - mass, volume, surface area, density, etc. They can all be stored in a map using std::map<std::string, quantity> (quantity represents a number and a unit). In this case, it does make sense to make "mass" a property of a quantity. A quantity represents just a number and a unit. That it can be used to capture the mass of a Part does not change what the quantity abstraction is.

Yes lookup/search has gone from O(1) to O(n) but has MyClassWithName violated anything?

You define a class called MyClassWithName only if it makes sense as a type, not as way to capture the name in a list that obviates the need for a map/dictionary for lookup purposes. Besides, you could go ahead and use a Dictionary<string, List<MyClassWithName>> to make the lookup more efficient.

Answer 3

It is important that a class shouldnt have extra fields unrelated to that class.

For example if you did add some random string you were using to index a collection of that class in one place. Then logically you would add some random integer you were using to index another collection somewhere else.

The class would balloon with extra properties.

However, I have found that, classes of which I need collections, are usually entities, and as such always have an Id field.

So in your situation I would be asking myself "why doesnt this class have an id field I can use as my index?"

Answer 4

I think you're conflating lookup keys and properties.

Lookup keys occur in the context of a keyed container class (e.g. a hash). If you're discussing a non-container class like Person, Organization, Membership, etc. then it doesn't make sense to speak of lookup keys because there are none.

However, if you're thinking about storing instances of class in a container then one of the properties could be used as a lookup key.

First, you should decide whether the class should have the property, i.e. you must answer the question "Does my domain model justify defining the property on this class?". Second, you decide what the keys in your collection are.

I'd also like to note that in your example not only the time complexity changed but also:

1. The interface exposed by the collection.
2. List<MyClassWithName> can store duplicates. Dictionary<string, List<MyClass>> cannot.
3. List<MyClassWithName> is ordered. Dictionary<string, List<MyClass>> is not.