• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Regarding Interface

 
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 1166
17
Netbeans IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 1166
17
Netbeans IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 1051
5
Hibernate Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 1166
17
Netbeans IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Hibernate Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic