Great questions! > Hi, Philip, > > (1) When we rename a attribute or move the attribute from > keyValStringMap to pMap, do we need to deleted the old entries in > keyValStringMap and keyValMap?
It generally doesn't hurt to leave them there, since anyone accessing these values should do it through the wrapper class. I guess, if the objects were large, it might help garbage collection to null the entries out. > (2) It seems in SensorDataEntry, whenever you put something in > keyValStringMap, you also put a corresponding version in keyValMap. > What > if I only put things in keyValStringMap? For now, I suggest you follow the pattern. This introduces a little inefficiency, but avoids subtle bugs. > (3) For attributes moved to pMap, do we still need to provide > access > method, or do we just let use dig into pMap themselves? This is an example of a "developer's choice". All wrapper classes inherit the methods getProperty(String) and getProperty(String, String), which is what external clients will use to access the property map. (There is no reason for a client to manipulate the SensorDataPropertyMap instance themselves). So, it's fine to simply let clients get properties using these two accessors. However, in some cases, you might want to provide an accessor for convenience purposes. For example, there might be an "optional" property on the pMap that contains an integer represented as a String. You might decide that, to be nice to your user, you will provide an accessor for that property that returns the int representation. Of course, you have to figure out what to do when the property doesn't exist! > (4) If we decide to provide access methods for optional fields, > then if > that filed does not exist, do we return default value or throw > exception? Another great question. One idea would be to force the client to provide a default value that would be returned to them when the property doesn't exist. So, if your optional property is a color, then you could provide: getColor(String) where the passed string is returned when no Color exists. This is a bit nicer for the client than simply returning null. (Of course, the client could always pass null as the default if they wanted that behavior.) If you do decide that you want to throw an exception, then the client would need to invoke hasProperty(String) before getProperty(), which is inherited to all wrapper classes from SensorDataEntry, so that they can tell whether the property exists before invoking the accessor. This is certainly very reasonable behavior. Whatever your choice, it would be gracious to document it in the JavaDocs. Cheers, Philip
