aspose file tools*
The moose likes Java in General and the fly likes Regarding Interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Regarding Interface" Watch "Regarding Interface" New topic
Author

Regarding Interface

santhosh kumar vk
Ranch Hand

Joined: Aug 25, 2009
Posts: 146
Hi,

For example interface have four method i need to implement only one method, Could you please tell me how to implement only one method.

Thanks,
Santhosh Kumar V.K
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5019
    
    8

You can't. You have to provide at least an empty/do-nothing implementation of each interface method or declare the ones you don't want to implement as abstract (but your class will have to be declared abstract as well). Another alternative is to throw an OperationNotSupportedException in the methods that you don't want to implement.

Junilu - [How to Ask Questions] [How to Answer Questions]
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14352
    
  22

You can make your class abstract, but ofcourse that would mean that in order to use it, you'd have to make a non-abstract subclass, which implements the other three methods from the interface.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Richard Tookey
Ranch Hand

Joined: Aug 27, 2012
Posts: 1084
    
  10

You could also create a dynamic proxy that throws an exception for any method call other than the one you need to implement.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

The real issue, though is that by implementing an interface, you're agreeing a contract. You're saying, "I implement X, so I AM-AN X (the IS-A relationship) so I will do everything an X does (the four methods)." If you don't want to implement all the methods, then you're not really an X, so why are you claiming that you are?

There can be cases where empty implementations are fine. An event listener, for example. By implementing some particular listener/observer/etc. interface, you may have to implement methods to respond to several different events, but you maybe only care about 1 or 2 of them. In this case its fine to provide empty implementations for the others, since you're usually not really denying somebody of some service they're relying on.

And then there's the case where you implement the method but your implementation throws UnsupportedOperationException. That's a way to get around the compile-time requirement to implement it but not actually allow it to be called. That should be used very sparingly. For instance, some Collections, such as the List returned from java.util.Arrays.asList(), or those returned from Collections.unmodifiableXxx(), throw UnsupportedOperationException when you try to add to or remove from the collection. Those are a special corner case and they have a valid reason for doing that (although you could argue that there should have been separate modifiable and unmodifiable types declared at the root of the Collections Framework, but those approaches have their drawbacks as well).

In the end, if comes down to this: Why do you want to call yourself an X if you're not going to do the things an X does?
Richard Tookey
Ranch Hand

Joined: Aug 27, 2012
Posts: 1084
    
  10

Jeff Verdegan wrote:
In the end, if comes down to this: Why do you want to call yourself an X if you're not going to do the things an X does?


1) Creating mock objects for test purposes; you may only want limited functionality for a particular test.
2) Backwards compatibility when an interface changes and you don't need/want to implement the changes. When upgrading a program (to work both with the current JRE and with a later JRE) that used a connection pool to trace usage I found that SQLConnection had had methods added that were not needed.
3) Creating a cut down version of some system when one does not need all the methods defined in one of the communication classes. For example, the HttpServletRequest passed to the get() method in a very much reduced Servlet container.

There are bound to be more examples.

Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Richard Tookey wrote:
Jeff Verdegan wrote:
In the end, if comes down to this: Why do you want to call yourself an X if you're not going to do the things an X does?


1) Creating mock objects for test purposes; you may only want limited functionality for a particular test.
2) Backwards compatibility when an interface changes and you don't need/want to implement the changes. When upgrading a program (to work both with the current JRE and with a later JRE) that used a connection pool to trace usage I found that SQLConnection had had methods added that were not needed.
3) Creating a cut down version of some system when one does not need all the methods defined in one of the communication classes. For example, the HttpServletRequest passed to the get() method in a very much reduced Servlet container.

There are bound to be more examples.



I know there are valid cases. I described a couple of them. I wasn't asking rhetorically and in general. I was directly and literally asking the OP, for this particular case, why he wants to do this. Based on his response, people can advise him of which approach is most appropriate, or if he needs to rethink his design and not do that.
James Boswell
Bartender

Joined: Nov 09, 2011
Posts: 1030
    
    5

1) Creating mock objects for test purposes; you may only want limited functionality for a particular test.


This isn't really a valid scenario. In this case, you would mock what you need to mock and stub the rest.
Richard Tookey
Ranch Hand

Joined: Aug 27, 2012
Posts: 1084
    
  10

James Boswell wrote:
1) Creating mock objects for test purposes; you may only want limited functionality for a particular test.


This isn't really a valid scenario. In this case, you would mock what you need to mock and stub the rest.


What am I missing? Stubbing methods one does not need for a test is exactly what I meant by 'limited functionality' .
James Boswell
Bartender

Joined: Nov 09, 2011
Posts: 1030
    
    5

Richard

What I meant was you don't really need to be concerned about the limited functionality of a mock object. Your backwards compatibility scenario is a better one.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Regarding Interface