tag:blogger.com,1999:blog-23939980.post115617037648626086..comments2023-09-25T17:29:29.440+10:00Comments on Java and other things: Tricky instanceof operatorAnonymoushttp://www.blogger.com/profile/11568089987006666223noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-23939980.post-64649563225024807052011-07-20T05:22:16.043+10:002011-07-20T05:22:16.043+10:00Nice article. One question though: how come you fi...Nice article. One question though: how come you first explain why it is not necessary to check for <i>null</i> when using <i>instanceof</i>, but within your "recommended" <i>equals()</i> you do it anyhow?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23939980.post-80531140447380528752009-12-10T03:31:26.673+11:002009-12-10T03:31:26.673+11:00I ran across this blog when thinking about my use ...I ran across this blog when thinking about my use of the instanceof operator and decided to try a different approach. Thing is, I can't think of another way, so could you please point me in the right direction?<br /><br />I have Person that have their emailaddresses stored in different places, so I created different extends and when looking up the emailaddress I did the instanceof to determine which lookup implementation to use.<br />I was thinking of having Person implement IEmail for String getEmail() and create a IEmailProvider but how do I hook these together? How do I know which one to use?<br /><br />Thanks,<br />DavidAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-23939980.post-31453659241939364022007-11-29T08:05:00.000+11:002007-11-29T08:05:00.000+11:00Thank You for the information!Thank You for the information!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23939980.post-92214833319745133192007-10-07T10:01:00.000+10:002007-10-07T10:01:00.000+10:00Thank you Giftiger! I corrected it.Thank you Giftiger! I corrected it.Anonymoushttps://www.blogger.com/profile/11568089987006666223noreply@blogger.comtag:blogger.com,1999:blog-23939980.post-10429896088330911482007-10-06T02:34:00.000+10:002007-10-06T02:34:00.000+10:00Objects in java are case-sensitive. "system.out.pr...Objects in java are case-sensitive. "system.out.println" will not work.giftiger_wunschhttps://www.blogger.com/profile/02746598889009699432noreply@blogger.comtag:blogger.com,1999:blog-23939980.post-39387815897214894402007-09-19T10:37:00.000+10:002007-09-19T10:37:00.000+10:00I cannot see the other cases in your short example...I cannot see the other cases in your short example therfore it is hard to argue for or against what you are saying.<BR/><BR/>I don't see the reason for you to use <I>instanceof</I> operator. If every class is a sub-class of the <I>BaseClass</I> and implements its own <I>validate()</I> method you do not need to check for its class type. Simple call <I>validate()</I> method and it'll perform validation specific to its own implementation.<BR/><BR/>However, if some of your classes extend other base class as well you have a case of mixing pears with apples. In such case, I would suggest for your base classes to implement a common interface, which can be as simple as a <I>validate()</I> method. Then you will not need to check for class type or cast your objects to a particular class.Anonymoushttps://www.blogger.com/profile/11568089987006666223noreply@blogger.comtag:blogger.com,1999:blog-23939980.post-60389481750122044382007-09-19T05:42:00.000+10:002007-09-19T05:42:00.000+10:00Is this bad design? - I have a base abstract class...Is this bad design? - <BR/><BR/>I have a base abstract class BaseClass that specifies some methods including validate().<BR/><BR/>All access to my logic is through a single Class which checks: if (A instanceof BaseClass) A.validate();<BR/>Where the validation would change depending on the actual class extending BaseClass.<BR/><BR/>Am I naive?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23939980.post-63749713766100185022007-07-20T18:50:00.000+10:002007-07-20T18:50:00.000+10:00Will, thank you for your comment! It actually make...Will, thank you for your comment! It actually makes a good point.<BR/><BR/>There are many applications where we have seen similar approach. Inheritance is good, don't get me wrong, but it's not the answer to all problems of code extensibility.<BR/><BR/>Your code sample is a typical example, where the code would greatly benefit from composition rather than a bit out-stretched Business-User inheritance. It's hard to say that <I>a business is a type of a person</I>. You could easily say that a business can consist of one or more people, but it is not same entity type.<BR/><BR/>If you had Person and Business objects that do not inherit from same root, you could overload a method to accept one or the other - just another way to avoid <I>instanceof</I> operator.Anonymoushttps://www.blogger.com/profile/11568089987006666223noreply@blogger.comtag:blogger.com,1999:blog-23939980.post-8274406777975979192007-07-20T14:05:00.000+10:002007-07-20T14:05:00.000+10:00>> If you need to find out the implementation firs...>> If you need to find out the implementation first (using instanceof operator), and then behave accordingly - it is a "smell". <BR/><BR/>I agree that instanceof is bad if you're using it to test for implementation, but what if you need to figure out if an object implements an interface?<BR/><BR/>Consider a user account system, which has two different kinds of users, Person and Business:<BR/><BR/>interface User {...};<BR/><BR/>interface Person extends User {<BR/> Date getBirthDate();<BR/> ...<BR/>}<BR/><BR/>interface Business extends User {<BR/> Person getPresident();<BR/> ...<BR/>}<BR/><BR/>If you have logic that depends on whether a user is a Person or a Business, it seems appropriate to use 'instanceof' here. The alternative using polymorphism requires methods in the super-interface for determining what sub-interfaces are implemented. Adding new kinds of Users would require adding more methods or enum constants to User.<BR/><BR/>Or is it poor design to treat people and businesses differently? :-DWill Lesliehttps://www.blogger.com/profile/14699326609813349977noreply@blogger.comtag:blogger.com,1999:blog-23939980.post-76969728588120788442007-04-15T09:51:00.000+10:002007-04-15T09:51:00.000+10:00I think that you might have a problem with the des...I think that you might have a problem with the design. If you need to implement classes B and C in a way that they depend on the implementation of the object passed in as a parameter.<BR/><BR/>Inheritance should give you the ability to do different things to same objects.<BR/><BR/>If you need to find out the implementation first (using <I>instanceof</I> operator), and then behave accordingly - it is a "smell". <BR/><BR/>I can see the problem in two places here:<BR/>1) in classes B and C: maybe you should use different method (one in B, another in C class) for these two types (method overloading might help). If you need to do something different on each time, maybe it's better to pass these into different methods.<BR/>2) in the objects received as parameters: if you need to call different methods on these objects, consider having a common method that delegates the call to a desired method.<BR/><BR/>Which method is better depends on what exactly you are trying to do differently.<BR/><BR/>Let me know if this helps. If I wasn't clear enough I can try to give you some examples (code examples).Anonymoushttps://www.blogger.com/profile/11568089987006666223noreply@blogger.comtag:blogger.com,1999:blog-23939980.post-54635872935411151682007-04-14T06:49:00.000+10:002007-04-14T06:49:00.000+10:00I have a little problem with your last statement t...I have a little problem with your last statement that instanceof should be used in only equals.<BR/><BR/>Lets say there is a jar file which contains an abstract class A. We want to use this jar file and A class in our code so that we can extend A to two different classes B and C. In A has an abstract method which needs to be implemented in B and C, but B and C expects different kind of objects as input to that function. So i think the only option is to pass object in abstract method and do instanceof checks in implementation in B and C.<BR/>Lemme know what do you thinkAnup Mayankhttps://www.blogger.com/profile/14250912395964533108noreply@blogger.comtag:blogger.com,1999:blog-23939980.post-1156895545363351642006-08-30T09:52:00.000+10:002006-08-30T09:52:00.000+10:00Yes you are right, the first comparison for null i...Yes you are right, the first comparison for <I>null</I> is not necessary as the <I>instanceof</I> operator will take care of it.Anonymoushttps://www.blogger.com/profile/11568089987006666223noreply@blogger.comtag:blogger.com,1999:blog-23939980.post-1156849440824760322006-08-29T21:04:00.000+10:002006-08-29T21:04:00.000+10:00So does that mean that the first check for null i...So does that mean that the first check for null in an equals method is not nessacary?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-23939980.post-1156328734590643952006-08-23T20:25:00.000+10:002006-08-23T20:25:00.000+10:00Thanks, mate!I'm pleased to hear you (and hopefull...Thanks, mate!<BR/><BR/>I'm pleased to hear you (and hopefully many others) appreciate my blogs.Anonymoushttps://www.blogger.com/profile/11568089987006666223noreply@blogger.comtag:blogger.com,1999:blog-23939980.post-1156299132117391872006-08-23T12:12:00.000+10:002006-08-23T12:12:00.000+10:00Hey great blogsite. I found your website to be rea...Hey great blogsite. I found your website to be really informative and helpful. In fact, I did learn a few things after looking through some of the articles posted here. Keep up the good work, thanks.Anonymousnoreply@blogger.com