简体   繁体   中英

Annotating methods with no implementation

In the interest of clean and beautiful code, I've been looking for an answer to a question that's popped up whist documenting my latest project.

Often times, there will be an abstract class or interface with methods requiring implementation; and occasionally, the class inheriting these methods have other specific and unique methods which make those inherited obsolete, and thus never referenced. To avoid adding functionality where functionality is not used, I've left these obsolete inherited methods empty, and commented on why they are so. Still, I feel that there's more I should do, but could not come up with an answer to what, other than to give it the deprecated annotation. This would ensure that anyone attempting to use the method would realize that it is not supported, and would therefore either use the more appropriate class specific alternatives, or add in the implementation. However, I've always thought of the deprecated annotation as belonging solely to content which was supported at one point, and is planned to be removed. Whereas in my case, the content has never been supported and has is not planned to be removed.

Would the deprecated annotation be appropriate here? Is there a more appropriate alternative? Or is it considered ill practice to leave these inherited methods without proper implementation, even if considered obsolete.

I appreciate your time and any possible feedback you may offer. Thank you, - Justis

The @deprecated annotation exists to notify users that certain methods will be removed in the future. The only reason for not removing them right away is that it would break existing code. In your case, it seems like your might be abusing inheritance. Extending from a class and not implementing the expected behavior is a code smell which is called Refused Bequest What is a Refused Bequest?

As NickL points out, your approach to inheritance sounds weird. However, I want to clear up a misconception regarding deprecation.

Many developers think that deprecating an API means announcing it will be removed, but this is not the only use case (as described in relevant articles of eg Java 7 andJava 9 ):

The API is dangerous (for example, the Thread.stop method).

There is a simple rename (for example, AWT Component.show/hide replaced by setVisible ).

A newer, better API can be used instead.

The deprecated API is going to be removed.

So it is in fact entirely correct to put the @Deprecated annotation on your methods. Be sure to also add the Javadoc @deprecated tag with an explanation of your reasoning, and mention that the method is not currently intended to be removed.

If you change your mind on one of these methods or want to deprecate others with the intention of removing them, mention that in the @deprecated Javadoc tag. If you use Java 9 and later, you should then also set the new forRemoval flag to true (it defaults to false ):

@Deprecated(forRemoval=true)

That feature is calledEnhanced Deprecation .

More details could be found in my answer to Java Deprecated APIs and SupressWarning "deprecation" - practical approach .

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM