tag:blogger.com,1999:blog-14570545.post115237933168509371..comments2023-10-03T14:02:23.078+02:00Comments on Thoughts and Fragments: Java should provide interface level equalitySergio Bossahttp://www.blogger.com/profile/09315991044338298083noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-14570545.post-1152693184637002672006-07-12T10:33:00.000+02:002006-07-12T10:33:00.000+02:00Valerio Schiavoni said... > you can obtain the sam...Valerio Schiavoni said... <BR/><BR/>> you can obtain the same effect in pure <BR/>> java relying on the dynamic proxies <BR/>> mechanism<BR/><BR/>Call it Dynamic Proxies, call it AOP ... it is always extra code to write ;)<BR/>I meant it would be better to have this feature fully integrated in the Java language.<BR/><BR/>Regards,<BR/><BR/>Sergio B.Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152609681226784122006-07-11T11:21:00.000+02:002006-07-11T11:21:00.000+02:00hello Sergio,>using AOP is surely a viable solutio...hello Sergio,<BR/>>using AOP is surely a viable solution.<BR/>>However, would it not be a lot easier if >Java already had this capability?<BR/><BR/>you can obtain the same effect in pure java relying on the dynamic proxies mechanism (much like as the original spring-aop works when implementing mixin, as you probably know better than me).<BR/><BR/>ciao,<BR/>valeriovaleriohttps://www.blogger.com/profile/09766976654691797492noreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152607917728096522006-07-11T10:51:00.000+02:002006-07-11T10:51:00.000+02:00Alessio Pace said ...> But in the end is just ONE ...Alessio Pace said ...<BR/><BR/>> But in the end is just ONE entity (there <BR/>> is only one John Miller).<BR/>> Are we on the same line now? Hope so :-)<BR/><BR/>Yes, we are :)<BR/><BR/>Thanks,<BR/>Cheers,<BR/><BR/>Sergio B.Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152554060515828082006-07-10T19:54:00.000+02:002006-07-10T19:54:00.000+02:00Hi Sergio, thanks for the answer and let me quote ...Hi Sergio, <BR/>thanks for the answer and let me quote and comment again, I think I see where we got into confusion :-D<BR/><BR/><I><BR/>What is John in our domain?<BR/>A Customer entity.<BR/>Then, if it is a StandardCustomer, a CustomerOfTheMonth, or both, it doesn't matter too much: it IS A Customer entity, always.<BR/></I><BR/><BR/>Yes, what I meant is indeed that it is ONE Customer entity, Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152539506225220072006-07-10T15:51:00.000+02:002006-07-10T15:51:00.000+02:00Gianugo Rabellino said...> I still contend that re...Gianugo Rabellino said...<BR/><BR/>> I still contend that relying on equals() <BR/>> to express business-level equality is <BR/>> wrong.<BR/><BR/>Yes, I agree: if equality is a strong business concept, implementing it as a separate method could be a better thing.<BR/><BR/>However, this was not my point of discussion, and I still think that if Java provided interface level equality, it would be a Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152539179434960192006-07-10T15:46:00.000+02:002006-07-10T15:46:00.000+02:00Alessio Pace said...> I get the point. The problem...Alessio Pace said...<BR/><BR/>> I get the point. The problem is that I <BR/>> misunderstood your previous comment (the <BR/>> part I quoted), because I thought you <BR/>> were <BR/>> speaking about having 2 instances of <BR/>> John <BR/>> under two different types<BR/><BR/>No, I was not talking about this, even if I think this is not a problem, nor a weird thing.<BR/>If you carefully think, we Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152522327624372512006-07-10T11:05:00.000+02:002006-07-10T11:05:00.000+02:00I still contend that relying on equals() to expres...I still contend that relying on equals() to express business-level equality is wrong. If you consider equals() as the Java counterpart of pointer equivalence in C, this becomes apparent. You should also consider how equals() requires (but doesn't force) to override hashCode() to understand why you'd be better served by providing an explicit equality contract at the business level. Leave equals() Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152460335129295702006-07-09T17:52:00.000+02:002006-07-09T17:52:00.000+02:00Hi Sergio,I get the point. The problem is that I m...Hi Sergio,<BR/><BR/>I get the point. The problem is that I misunderstood your previous comment (the part I quoted), because I thought you were speaking about having 2 instances of John under two different types, and that *really* sounded weird! :-)<BR/><BR/>Anyway, interesting discussion, it seems like the part-2 of your other entry about solving interface contracts :-)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152456647399577362006-07-09T16:50:00.000+02:002006-07-09T16:50:00.000+02:00Hi Valerio,thanks for your interesting point: usin...Hi Valerio,<BR/><BR/>thanks for your interesting point: using AOP is surely a viable solution.<BR/>However, would it not be a lot easier if Java already had this capability?<BR/><BR/>Regards,<BR/><BR/>Sergio B.Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152455576624910012006-07-09T16:32:00.000+02:002006-07-09T16:32:00.000+02:00Hi Alessio,thanks for answering.> Sorry, but how c...Hi Alessio,<BR/><BR/>thanks for answering.<BR/><BR/>> Sorry, but how can the same John Miller <BR/>> be <BR/>> represented by two different objects and <BR/>> even more, two different types? If the <BR/>> type of an entity can change in time, <BR/>> then <BR/>> you can't use subclassing to express <BR/>> that <BR/>> changing concept, you need to introduce <BR/>> State/Strategy there.<BR/><BR/>Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152446414218823392006-07-09T14:00:00.000+02:002006-07-09T14:00:00.000+02:00Hello Sergio,maybe what you want is to handle the ...Hello Sergio,<BR/>maybe what you want is to handle the equality between classes as an aspect. <BR/>In this perspective, you can easily provide a default implementation for all classes implementing your Customer interface (this technique, as you may already, produces code sometimes referred as mixin).<BR/><BR/>A possible implementation, using AspectJ, would be:<BR/><BR/>public interface Customer {valeriohttps://www.blogger.com/profile/09766976654691797492noreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152442076297044012006-07-09T12:47:00.000+02:002006-07-09T12:47:00.000+02:00Say you have a StandardCustomer: John Miller. John...<I>Say you have a StandardCustomer: John Miller. John, after a single order of one thousand dollars, becomes cutomer of the month. So, John will always be a StandardCustomer, but until the end of the month, it will be also a CustomerOfTheMonth, with additional behaviour, business rules or alike. So, John will be represented by two different "subtypes", say depending on the context, but into your Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152403366998962062006-07-09T02:02:00.000+02:002006-07-09T02:02:00.000+02:00Hi Ugo,thanks for answering!> it's possible for a ...Hi Ugo,<BR/><BR/>thanks for answering!<BR/><BR/>> it's possible for a class to extend <BR/>> BaseCustomer and still break the <BR/>> contract <BR/>> by overriding the equals method. You <BR/>> should really make it final.<BR/><BR/>Yes, I fully agree.<BR/><BR/>> However, I second Gianugo's question: <BR/>> why should two instances of different <BR/>> classes be considered equal?<BR/><BR/>When you Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152403132450313302006-07-09T01:58:00.000+02:002006-07-09T01:58:00.000+02:00Hi Gianugo, thanks for your answer.> 1. add an equ...Hi Gianugo, <BR/><BR/>thanks for your answer.<BR/><BR/>> 1. add an equivalentTo() method in your <BR/>> interface if you need to fullfil a <BR/>> specific business need<BR/><BR/>Yes, interesting point. However, I think the client user could get confused: why the API provides an equivalentTo() method if there's also the equals() one?<BR/><BR/>> 2. use instanceof BaseCustomer in your <BR/>> Sergio Bossahttps://www.blogger.com/profile/09315991044338298083noreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152400516572680032006-07-09T01:15:00.000+02:002006-07-09T01:15:00.000+02:00Not only that, but it's possible for a class to ex...Not only that, but it's possible for a class to extend BaseCustomer and still break the contract by overriding the equals method. You should really make it final.<BR/><BR/>However, I second Gianugo's question: why should two instances of different classes be considered equal?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-14570545.post-1152390768147102342006-07-08T22:32:00.000+02:002006-07-08T22:32:00.000+02:00Well, for one it would not be enough to implement ...Well, for one it would not be enough to implement equals() given the hashCode() contract. Then again, I'm a bit puzzled at why two instances of different classes should actually be equal. Two suggestions to overcome this "limitation":<BR/><BR/>1. add an <I>equivalentTo()</I> method in your interface if you need to fullfil a specific business need<BR/><BR/>2. use <I>instanceof BaseCustomer</I> in Anonymousnoreply@blogger.com