2

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?

  • You and your OP friend seem to be overthinking this, too obsessed with being "correct" or violating some arbitrary principle to recognize the simple, pragmatic truth you articulated in the last sentence of your question: lookup has gone from O(1) to O(n). That's all that really matters, don't you think? – Robert Harvey Apr 28 '17 at 22:04
  • @RobertHarvey That is all that really matters? Premature optimization? If it adds meaning to the class then it adds value in my book. Simpler code. Until n gets big O(n) can be pretty fast. I have an app were I use a sorted List with binary search and beat Dictionary speed at 1 million items. It loads faster even with the sort and uses 1/2 the memory. – paparazzo Apr 28 '17 at 22:13
  • Well, premature optimzation doesn't equal poor planning. If this system might ever grow to a non-trivial size (or use a database), you're going to need a key. Review your software requirements or specifications and decide if a key is warranted or not. – Robert Harvey Apr 29 '17 at 15:44
2

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.

  • It is not my friend. It is just an example. I know it can be done both ways. The stated question is does making a lookup a property violate any rule or recommended practice. In .NET there is a KeyedCollection for single property with hashed lookup. – paparazzo Apr 28 '17 at 23:37
  • @Paparazzi: No there is no such rule in the general. Whether a property belongs to an object is determined by guidelines like single responsibility, separation of concerns, high cohesion low coupling and so on, but the all depends on the meaning and purpose of the objects in question. The fact that there exists a dictionary keyed on some value does not have any bearing on whether this should be a property on the object. – JacquesB Apr 29 '17 at 6:30
1

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.

0

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?"

-2

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.
  • I noticed two downvotes - I'd appreciate a comment that'd help me understand where my thinking is wrong. – Greg Navis Apr 29 '17 at 4:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.