Alternative to using a string as a key?
-
I sometimes come across situations where I could use a string type to represent a unique key in something (sorry for being vague)... An example:
ConnectSensor(new OffScreenSensor(),"screen");
Where the "screen" part is used to identify the OffScreenSensor object in a dictionary somewhere. I could use an Enum as a replacement but was wondering if any one here has a better way of dealing with stuff like this? I don't like the idea of having to look back to see the names of keys I have named before :laugh:
-
I sometimes come across situations where I could use a string type to represent a unique key in something (sorry for being vague)... An example:
ConnectSensor(new OffScreenSensor(),"screen");
Where the "screen" part is used to identify the OffScreenSensor object in a dictionary somewhere. I could use an Enum as a replacement but was wondering if any one here has a better way of dealing with stuff like this? I don't like the idea of having to look back to see the names of keys I have named before :laugh:
strings are fine for identifying, i.e. naming, objects by humans. And I would suggest you store the sensor's name inside the Sensor object, hence turn it into a constructor parameter! :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
strings are fine for identifying, i.e. naming, objects by humans. And I would suggest you store the sensor's name inside the Sensor object, hence turn it into a constructor parameter! :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Ok thanks, sounds like I am on the right track :)
-
Ok thanks, sounds like I am on the right track :)
Yeah, I would just derive a class from Sensor that manages its own name, something like a GUID for example.
-
Yeah, I would just derive a class from Sensor that manages its own name, something like a GUID for example.
Names are supposed to be pronounceable, IMO GUIDs aren't. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
I sometimes come across situations where I could use a string type to represent a unique key in something (sorry for being vague)... An example:
ConnectSensor(new OffScreenSensor(),"screen");
Where the "screen" part is used to identify the OffScreenSensor object in a dictionary somewhere. I could use an Enum as a replacement but was wondering if any one here has a better way of dealing with stuff like this? I don't like the idea of having to look back to see the names of keys I have named before :laugh:
venomation wrote:
if any one here has a better way of dealing with stuff like this?
Depends on the context of 'screen'. Do you use it as a display name anywhere? Is it viewable by a user anywhere, like a config value? Then you need to map to a different value in your code. Mapping of course could still be to a string value. The real issue however is that you want a programmatic value which will not change due to human concerns.
-
venomation wrote:
if any one here has a better way of dealing with stuff like this?
Depends on the context of 'screen'. Do you use it as a display name anywhere? Is it viewable by a user anywhere, like a config value? Then you need to map to a different value in your code. Mapping of course could still be to a string value. The real issue however is that you want a programmatic value which will not change due to human concerns.
The idea is that other components can get another component based on its key. At the moment there is no configuration file aspects, but I may consider it... The problem is that one type of component can be added multiple times, some of them can be configured to act more generically, in theory I could install two OffScreenSensor's but with different keys.
-
Names are supposed to be pronounceable, IMO GUIDs aren't. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
True... but why have a pronounceable name for something that doesn't need one? :).
-
I sometimes come across situations where I could use a string type to represent a unique key in something (sorry for being vague)... An example:
ConnectSensor(new OffScreenSensor(),"screen");
Where the "screen" part is used to identify the OffScreenSensor object in a dictionary somewhere. I could use an Enum as a replacement but was wondering if any one here has a better way of dealing with stuff like this? I don't like the idea of having to look back to see the names of keys I have named before :laugh:
To add a key to a Dictionary, it must be unique. If there is a property of the Sensor object that is unique, use it in place of the made-up string. This will help you recreate the entire object from this key. If you just need a random string and you don't care about what it is, use a GUID.
-
I sometimes come across situations where I could use a string type to represent a unique key in something (sorry for being vague)... An example:
ConnectSensor(new OffScreenSensor(),"screen");
Where the "screen" part is used to identify the OffScreenSensor object in a dictionary somewhere. I could use an Enum as a replacement but was wondering if any one here has a better way of dealing with stuff like this? I don't like the idea of having to look back to see the names of keys I have named before :laugh:
If your goal is to make it easy for you to select one of the available, limited, set of choices of "unique keys" during development: then using an Enum makes very good sense: it gives you Intellisense display of the choices possible. But that Enum could just as well be passed, as Luc pointed out, as an argument to a constructor overload or whatever for the OffScreenSensor class: unless, of course, you make use of that second parameter in other important ways in the function you call. But, what's the usage/relationship of the new "OffScreenSensor" you create and pass as a parameter, along with the second parameter that serves a unique key to some (we assume) existing OffScreenSensor you are going to access by using the unique key? That's what's puzzling here. Is the new "OffScreenSensor" some temporary entity that's never preserved: outside the scope of the functional call: never entered in your storage (dictionary or whatever) for the other (assume instances of ?) OffScreenSensor's ? Are the OffScreenSensor instances in the (assumed) Dictionary sub-classed "flavors" of some master class OffScreenSensor ? Is there a security aspect here ? Without some sense of what your "big picture" goals are here, it's difficult to respond meaningfully. In a technical forum like this, "vague" is automatically amplified :) best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
-
I sometimes come across situations where I could use a string type to represent a unique key in something (sorry for being vague)... An example:
ConnectSensor(new OffScreenSensor(),"screen");
Where the "screen" part is used to identify the OffScreenSensor object in a dictionary somewhere. I could use an Enum as a replacement but was wondering if any one here has a better way of dealing with stuff like this? I don't like the idea of having to look back to see the names of keys I have named before :laugh:
-
The idea is that other components can get another component based on its key. At the moment there is no configuration file aspects, but I may consider it... The problem is that one type of component can be added multiple times, some of them can be configured to act more generically, in theory I could install two OffScreenSensor's but with different keys.
That is a different problem however than using a key.
venomation wrote:
some of them can be configured to act more generically, in theory I could install two OffScreenSensor's but with different keys.
Which only apples to what I said if when you say "install" then it refers to something that is basically code, and not something that a 'user' would muck with. If it does refer to 'code' then you are not using a "component" but rather an instance of a component. So the name refers to an instance even if most only have a single instance.
-
The idea is that other components can get another component based on its key. At the moment there is no configuration file aspects, but I may consider it... The problem is that one type of component can be added multiple times, some of them can be configured to act more generically, in theory I could install two OffScreenSensor's but with different keys.
Its generally not a good idea to use strings as keys to get components like that. My boss is a notorious mispeller. Do you really want to spend time tracking down why your app doesn't work because somebody spelled it "scren" in 3 out of 100 places? GUIDs as I suggested earlier actually wouldn't be AS prone. Why? I'd probably type in "screen" myself because I can do that faster then copy & pasting from somewhere. With a GUID? I'm not going to type that in. Thats going to be a strict c&p. Is adding a component multiple times "theoretical"? or is it really going to happen? Would it be more practical to have a single instance of OffscreenSensor that can sense things from multiple locations? Instead of doing something like: Components["Screen1"].EventHappened += you could do something like: IScreenSensor sensor = ServiceLocator.GetService(); sensor.GetScreen(1).EventHappened += sensor.GetScreen(2).EventHappened += etc. string keys are also prone to lazy search and replace issues :).
-
I sometimes come across situations where I could use a string type to represent a unique key in something (sorry for being vague)... An example:
ConnectSensor(new OffScreenSensor(),"screen");
Where the "screen" part is used to identify the OffScreenSensor object in a dictionary somewhere. I could use an Enum as a replacement but was wondering if any one here has a better way of dealing with stuff like this? I don't like the idea of having to look back to see the names of keys I have named before :laugh:
Yeah, use an enum , or go for GUIDs
-
Its generally not a good idea to use strings as keys to get components like that. My boss is a notorious mispeller. Do you really want to spend time tracking down why your app doesn't work because somebody spelled it "scren" in 3 out of 100 places? GUIDs as I suggested earlier actually wouldn't be AS prone. Why? I'd probably type in "screen" myself because I can do that faster then copy & pasting from somewhere. With a GUID? I'm not going to type that in. Thats going to be a strict c&p. Is adding a component multiple times "theoretical"? or is it really going to happen? Would it be more practical to have a single instance of OffscreenSensor that can sense things from multiple locations? Instead of doing something like: Components["Screen1"].EventHappened += you could do something like: IScreenSensor sensor = ServiceLocator.GetService(); sensor.GetScreen(1).EventHappened += sensor.GetScreen(2).EventHappened += etc. string keys are also prone to lazy search and replace issues :).
SledgeHammer01 wrote:
Its generally not a good idea to use strings as keys to get components like that. My boss is a notorious mispeller. Do you really want to spend time tracking down why your app doesn't work because somebody spelled it "scren" in 3 out of 100 places? GUIDs as I suggested earlier actually wouldn't be AS prone. Why? I'd probably type in "screen" myself because I can do that faster then copy & pasting from somewhere. With a GUID? I'm not going to type that in. Thats going to be a strict c&p.
I would suggest unit testing and system testing to solve that problem. Additionally that also solves the problem where they typed in "alternativeScreen" (a valid component) when it should have been "screen" (also valid.) And myself I would be opposed to using a guid because that means that to figure out what component instance is in use one would need to look it up every time. However depending on the actual requirements I would probably use a generated enumeration.