Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Is there a better way to group and sort objects? Date: Tue, 14 Aug 2018 14:06:45 +0200 Lines: 66 Message-ID: References: <8c045ff4-98c5-4253-9136-b26b34cf8f77@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net d3HtzwA8dtiJX5wqDnSr3Ae4aMZJRAsN/JMLWzujinpoMHEFw= Cancel-Lock: sha1:I0Ju2fpJY5T/3csrMMxp/MGN1sI= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 In-Reply-To: Content-Language: en-US Xref: csiph.com comp.lang.java.programmer:38558 On 08.08.2018 16:50, Stefan Ram wrote: > Eric Douglas writes: >> I'm using toString() to pass out all values that make the >> address unique. This is my map key, so if my ship to source >> contains an address that matches everything from a mail to >> source I combine those to get one object that is flagged as >> both ship to and mail to. To combine the key must be the >> string, not the object as both objects would use unique >> object pointers if you use them as a key. >=20 > A class should be written so that its objects meaningfully > represent an entity, and the standard methods like > =C2=BBcompareTo=C2=AB and =C2=BBequals=C2=AB should implement the na= tural > ordering and equality properties of such an entity observing > all the contracts from java.lang.Object and Comparable. >=20 > These standard methods should not be tuned to "work" for a > specific use case (Map) when this compromises their natural > semantics or the standard semantics and contracts of the JDK > (java.lang.Object, java.lang.Comparable). >=20 > If such an entity then is to be used in an application where > a specific order or merge behavior is required that is /not/ > implemented by the normal ordering and equality behavior of > such an entity, one should not compromise the standard > methods of this entity by modifying them for a specific use > case, but instead use something like an adapter or some such. >=20 > For example, an object might have a method =C2=BBgetKey=C2=AB that > returns an object that is intended to be used as a key for > the object in certain maps. It is not obvious whether a > string is the best type for such a key. >=20 > =C2=BBtoString=C2=AB should return a meaningful string representatio= n > of an object for a human seeing its value in error or log > messages. It is not intended to provide a key to be used in maps. I could not agree more. A few more thoughts: It seems the class design can be improved, e.g. by separating out the=20 "8-10 fields that make up the address" in a class of its own. That=20 could have proper hashCode() and equals() implementations and maybe a=20 default order (once Eric catches up on the basics). I also think the flags should be removed altogether (basically leading=20 to the same result as above) since the sort order is determined by the=20 user ("One user wants to see all mail to addresses first, another needs=20 to see ship to addresses first."), i.e. it is not part of the=20 (presumably persistent) data but rather of the _use_ of it (i.e. viewing = on the screen or processing it for some purpose). There should=20 definitively be a Comparable instance that can be used as a Map key for=20 the different orders supported. Definitively use specific classes for=20 keys instead of abusing toString() for this! Cheers robert --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/