File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Regarding Interface

 
santhosh kumar vk
Ranch Hand
Posts: 152
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 6558
22
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Pie
Posts: 15150
31
Android IntelliJ IDE Java Scala Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Richard Tookey
Bartender
Pie
Posts: 1166
17
Java Linux Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Pie
Posts: 1166
17
Java Linux Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1051
5
Chrome Eclipse IDE Hibernate
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Pie
Posts: 1166
17
Java Linux Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1051
5
Chrome Eclipse IDE Hibernate
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic