Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Partially overriding a method? Date: Thu, 21 Apr 2011 15:58:41 -0400 Organization: albasani.net Lines: 90 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net +S2+wJ960LKd6gfo5k5pPV5H56niaGeoNhBx456toS31OwkAbbabZ5aoe68wC8hM+nH0bQkTl0axv3bj2RCIlw== NNTP-Posting-Date: Thu, 21 Apr 2011 19:58:28 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="14KQBwPrdslyC1V5ai5aVSZYHP+S3h62LI/ACV7RDmKHALVvHo4hzskMrqjcwflnTu9UaFsSdB7n6neLfNHN64IRfkIOI5WZdmqKpJoNkprmwDZUjakMPQjDMXT/7maJ"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 In-Reply-To: Cancel-Lock: sha1:3UmDDmIxUj3tc282CiVSp7V9xac= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3191 markspace wrote: > raphfrk@gmail.com wrote: >> I was wondering if it is possible to override a method but only for >> certain sub-classes of the method that the super-class supports. > Yes and no. As you discovered, overriding is all or nothing. You either > override or you don't. > > But you could add your own processing to do what you want with the "super" > keyword. > > > >> >> For example: >> >> class MainClass { >> public static void main(String[] args) { >> System.out.println("Started"); >> MainClass mc = new SubClass(); >> mc.check("Testing"); >> mc.check(7); >> } >> void check(Object x) { >> System.out.println(x.toString()); >> } >> } >> >> class SubClass extends MainClass { > void check(Object x) { > if( x instanceof String ) { > System.out.println("Sub class: " + x); > } else { > super.check( x ); > } >> } >> } >> > > The code changes above are untested. The presence of the 'instanceof' operation is often a red-flag marker of bad design. Polymorphism handles type resolution automatically. Doing it manually like this is a big oops. Josh Bloch and other writers warn against overload resolution on subtypes - it can be dicey. If you have a concept that a particular method overload should be an override, but the parent class doesn't sport that overload, you're trying to assert two contradictory things. You're trying to say that 'check(String)' is an override but that it isn't. As a result, you have to do funky type checks in the subtype. The upside is that you get what the OP asks for, if not what he wants - an override that can specialize for a covariant argument type. The idiom in the SSCCE I posted, as the output shows, will not treat 'check(String)' as a specialization if the variable is of the supertype - the compiler will invoke the 'check(Object)' form no matter what. It only knows about the specialization through a reference of the subtype. I'm not saying that the 'instanceof' dodge is a bad way to bandage an infelicitous design, only that its necessity stems from such a decision. Either 'check(String)' is part of the supertype contract or it isn't; trying to pretend that it is via subtype magic is not a great thing. You could just add the specialization to the parent type, or abandon the idea that you should have a specialization at all. Or perhaps abandon the idea that you should have a generalization in the supertype. OR ... you could make the specialization a generics parameter: public class DoesItOverride { public void check( T x ) { System.out.println( "Supertype: "+ x ); } } class Rider extends DoesItOverride { @Override public void check( String x ) { System.out.println( "Subbatype: "+ x ); } } -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg