Hi All, On Oct 11, 2011, at 7:40 PM, Brian Foster wrote:
> the problem with implementing an equals and hashCode function for the Product > object is that it is not always created from db data... many of the objects > in the structs package are 'fill what I know at the moment'... no guarantee > that any one member variable in the object will always be set... I totally agree with Brian on this. The lifecycle of any one of the FM objects in the o.a.oodt.cas.filemgr.structs (and furthermore in any o.a.oodt.*.structs package) is that any of the fields of the object may (or may not) be filled at any point in time. It really depends on the lifecycle of the object, and the downstream use of them in a service, in the core, or in some extension point. The objects are meant to be light-weight, and not representative of the *full* set of information at any point in time unless absolutely necessary (thereby lowering the total system footprint, etc.), making it more light-weight, etc. > for instance when a Product is created on the client side for an ingest the > productId is not set until after ingestion... also the current trunk > filemgr's Product object doesn't have an ingested or received time attach to > it... at least the last time I checked it didn't... lol... +1, you are right, it's still that way, for the above stated reasons. > so an equals method which say just checked against productId and productName > could give a false positive in some cases... for example making two > sequential calls to getProductById() then calling equals (assuming we > implemented it) on the 2 Product objects returned would return true... but if > the Product was updated between the 2 calls, equals really should return > false because the first Product object is out of date... +1 > and doing a deep equals on the Product object would make the operation > expensive... the Product object is more meant to be an information carrier... > I would recommend storing your Products in a Map<String,Product> where the > String key is ProductId +1, agreed. Using a Map<String, Product> structure is a good way to obviate this, and then to define some locally uniqueness key function inside of that map (or accept the uniqueness of the product ID which *should be* unique at least within a single FM catalog). Cheers, Chris > On Oct 11, 2011, at 4:46 PM, "Starch, Michael D (388L)" > <[email protected]> wrote: > >> Chris et all, >> >> Do you see any problems overriding the default equals, and hashCode methods >> in the Product class (checking by memory address/reference) to something >> that checks to see if the products logically represent the same thing (same >> id, name, etc)? >> >> My issue is the following, I receive data back from the database, with >> multiple lines representing a single product (this is a database thing, and >> the desired behavior). Thus if I iterate across the results, I will get >> multiple Product objects that represent one real Product (and contain >> equivalent member variables). In essence they are the same "Product". I >> can write cleaner, faster, code to combine the results, if I can test them >> for equality and hash them directly, without first pulling out the >> productName, or Id. >> >> This will be a problem if there is some code that expects two "Products" >> that have identical member variables to fail the equality test if they are >> distinct objects. >> >> Thanks, >> >> -Michael >> >> >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
