Optional methods in interface

The java tutorial for collections says these some methods in the List interface are optional
    Object set(int index, Object element);            // Optional
    void add(int index, Object element);              // Optional
    Object remove(int index);                         // Optional
    abstract boolean addAll(int index, Collection c); // Optionalhttp://java.sun.com/docs/books/tutorial/collections/interfaces/list.html
How can they be optional? Do you have to implement them and throw and UnsupportedException or something? This seems against the point of having an interface in the first place. If I use a class that imnplements an interface, shouldn't it be gauranteed that all the methods are implmented?
Thanks a lot for any help/comments...
Ryan Harris

You have to implement the methods, so I guess you
would just throw an UnsupportedException if you decide
this should not be supported.This is, of course, completley against the grain of OO design.
The interface should have been extended to incorporate the additional methods, and the implementations should derrive from the desired interface.
By having methods in an interface which 'aren't supported', the client of the interface then has a dependency on the implementation (I.e, it needs to know whether the implementation it is using supports the methods it is trying to use or not).
'Data Structures and Algorithms In Java' (Goodrich) contains collections which handle this type of thing in a much more OO way (I.e, extending the interfaces)

Similar Messages

Hi ,info need on container creation,methods,class,interface....

hi ppl,
Can anybody give me information on what is and how to create
container creation,methods,class,interface....with programs.

>
priyank dev wrote:
> hi ppl,
> Can anybody give me information on what is and how to create
> container creation,methods,class,interface....with programs.
Hi Dev,
Interface is just the skeleton of the class definition.
If you want to have your own code for all or any of the methods that interface is havings then you can create an instance of that interface and implement those methods with you own code.
That is the advantage of object oriented programming. And if you want to use the standard method or original method's functionality then you have call the method along with the class which implemented it like below
class => method1
For Imore information on interfaces Check this link.
http://help.sap.com/saphelp_nw04/helpdata/en/c3/225b6254f411d194a60000e8353423/frameset.htm
For creating classes you can follow this procedure.
Go with abap dictionary->select database table->provide the table for dev classs eg. V_TDEVC-> go for display option-> select utilities->select contents option-> select create dev class,
provide the name and short text,software component->create req.no.
with this dev class will be created.
Thanks
Nitesh
Edited by: Nitesh Kumar on Nov 18, 2008 10:56 AM

How to create a method in Interface Controller

Hi Guys,
        I am working with webdynpro ABAP sample application "Component usage" . There i got a issue like i am not able to create a method in Interface controller. There i am not able to edit anything. Can anybody please let me know how to do that.
            Thanks In Advance
Regards
Ravikumar

Hi Ravi,
          Check This
If one Web Dynpro component (parent component) needs access to another Web
Dynpro component (child component) the parent component can declare the use
of the child component. A specific component usage instance is then created and
the parent component accesses the functionality of the child component via its
component interface controller.
The only parts of a Web Dynpro component that are visible to the user, are the
interface controller and the interface view(s).
All Web Dynpro components have only one interface controller. Via the
interface controller, data, methods, and event handlers can be exposed to
other components.
Interface views represent the visual interface of a Web Dynpro component.
There is a one-to-one relationship between a Window and an interface view.
Each time a window is defined, a related interface view is automatically
generated, which makes the window accessible from outside the component.
The interface view only exposes those inbound and outbound plugs to the
component user that have the interface property checked. Methods and
context data of the window are not accessible via the related interface view.
If the component has no views, there is no need to have Windows. In this
case, the component will not implement an interface view. Such components
having no visual interface are known as faceless components.
Regards
Sarath

Static methods in interface (Yes, once again!)

I know there has been many questions about why static methods in interfaces are not allowed. I know it is forbidden by the JLS. But does anyone know the exact reason for this? Is it just a design issue or are there technical difficulties with allowing it?
I can't think of any reason that it should be impossible to allow static methods in interfaces. I don't even think it would be very difficult to do. More importantly, it could probably be done without breaking existing code and existing JVMs (not too sure about the last one).
So once again: Was the choice of not allowing static methods in interfaces a design choice or a technical choice?

A better example of what you are suggesting is surely ...
interface i {
    static void one();
class a implements i {
    static void one() {
        // do something
class b implements i {
    static void one() {
        // do something else
}What would be the point of ever doing this?
You cant call i.one() as the method doesn't exist without an instance of an implementing class.
To actually ever be able to use that method you would effectively be casting an INSTANCE of a or b -> i. If you have an instance of an a or b then there is absolutely no reason for that method to be static.
If you wanted to implement some sort of class (ie static) behaviour then class a could call its own internal static method from within the 'one' method.
To get right to the point ... there isn't one. If it gets added to the language (and I can't see it in my wildest dreams) then Sun have lost their marbles, surely?
Unless someone can give a good example of when it might be correct and useful to do so? I can't even see how it would be a convenience as it is completely unusable, no?

Protected Methods in Interfaces

Why don't interfaces allow you to declare protected methods? Is there a way around this?
The reason I ask involves a current project of mine. I have an inheritance hierarchy including an abstract Event base class with many concrete derived Events. I want to define many protected methods in the base Event class, which all my derived Events will use, in order to save me a lot of coding. I'm also trying to make my program reusable, and isolate the protocol changes to this Event hierarchy and a Packet hierarchy as well. For both these hierarchies, I want to implement interfaces that make sure that the programmer defines these necessary, protected methods. Yet I cannot declare protected methods in my interfaces!

> I have this same desire: to have protected
methods within interfaces.
Interfaces are not intended to (nor can they) provide
implementation.Yes, this is clear. Yet they "promise" an implementation. In the Java interface model, they only promise the public interface. I have yet to see why they cannot promise protected methods. I'm not really interested in code inheritance (reusing the code). I'm interested in what is called interface inheritance to achieve certain polymorphic goals.
>
> any design patterns that can be used to get
around this problem.
I'd suggest using composition rather than
inheritance. Let me know if I should explain
further.
Yes, I understand about composition (or delegation) as a way to "inherit" the functionality; however, I want to treat the subclasses polymorphically. I'm designing class library/frameworks that require a certain level of structure. The subclasses need to maintain the encapsulation provided by protected methods. I don't want external clients calling the protected methods, but the only way to achieve multiple (interface) inheritance is through Java's public interfaces, which then exposes the methods. I see no way around this problem. I'm not familar with the technical challenges of implementing multiple inheritance within compilers etc. At first glance, I don't see why allowing methods to be declared protected within the Java interface construct would cause serious technical problems.
~
P.S. Yes, this is an old thread...
Sorry, yes this is an old thread. I did some searching on this topic and this thread came up. Thanks for your reply.

Can I define a synchronized method in Interface?

I tried to define a Synchronized method in Interface, but it won't let me compile. So I took the modifier 'Synchronized' out.
When I implement this interface, I was able to implement this method as Synchronized.
Why?
Thanks!

Because synchronisation is an implementation detail and interfaces are not.
Dave

Disabling HTTP OPTIONS method

Hi
Can anyone tell me how I can disable the HTTP OPTIONS method in Sun One Web Server 6.0 SP4.
Thanks

1) Why would TRACE and OPTION request specifying HTTP 1.0 vs. 1.1 yield such different results?
Web Server 6.0 only implements the TRACE and OPTIONS methods for HTTP/1.1, not HTTP/1.0. This is reasonable as TRACE and OPTIONS are part of the HTTP/1.1 protocol and not the HTTP/1.0 protocol.
In other words, TRACE is always disabled for HTTP/1.0 requests, even if you don't use the set-variable work around.
2) Is the OPTIONS command a legitimate test of whether this fix works? If it is, has anyone managed to have the command return an "Allow:" line MINUS the TRACE?
Nope, not in Web Server 6.0. OPTIONS will always list TRACE. (Note that in Web Server 6.1, TRACE is not as tightly integrated into the server core. As a result, OPTIONS will conditionally list TRACE in 6.1.)
3) Has anyone managed to generate a 501 error message after specifying TRACE / HTTP/1.1 instead of 1.0?
Nope, not in Web Server 6.0.
4) Does this fix really work?
I wouldn't call it a fix; it's a work around. However, it does effectively disable TRACE. The work around is a bit of a kludge, resulting in the odd 413 status code.
The real "fix" appears in Web Server 6.1 where you can disable TRACE simply by commenting out the Service method="TRACE" fn="service-trace" line in obj.conf.

Why all the methods in interface should be implemented

why all the methods in interface should be implemented

Because you'll break the contract saying "this instance features all methods defined in that interface" otherwise.
In other words, as long as an interface isn't completely implemented by an instance, it's not validly implemented at all.

Optional implemenation for interface methods?

hi, is there a way of putting several methods of a interface to optional implemenation? such as one method name but different parameters, and put all of them to optional implemenation for classes that implements the interface? thanks :D

hi, is there a way of putting several methods of a
interface to optional implemenation? such as one
method name but different parameters, and put all of
them to optional implemenation for classes that
implements the interface? thanks :DNo.
If a class implements that interface, then it must either implement all the methods, or declare itself abstract.
You can do like the various XxxAdapter classes to in Swing. Create a concrete class that implements the interface, and give all its methods empty bodies. A subclass then overrides only those methods that it wants to actually do something with.
Note that I don't think this approach is usually a good one. If there are some methods that are optional, then maybe they should be in different interfaces, and classes can implement various combinations of your interfaces.

Problem in using methods in Interface, CharacterData in org.w3c.dom

Hi,
I am trying to use two methods provided by CharacterData Interface. The getData() and getLength() methods. It is giving error when I use it like this
String dat3 = myNode.getData();
Is there anything wrong in the way I am using it? Can somebody please help me with this?
Please find below the code I am using.
One more question - I have the below statement in my code which is giving an error when there is no data in the XML node.
String dat = myNode.getFirstChild().getNodeValue();
Is there any way to bypass this?
Thankyou
NodeList myNodeList=myElement.getElementsByTagName("EVENT-EXPIRY-DATE");
for (int i = myNodeList.getLength(); i>0;i--)
Node myNode = myNodeList.item(i-1);
boolean delflag = false;
String dat3 = myNode.getData();
int len = myNode.getLength();
}

CharacterData, which is an extension of Node, is the interface that define the getData resposability. In your code you try to use that method in an instance of type Node which doesn't have it.

Deprecated methods in Interfaces

Hi all,
I'm implementing an interface containing some deprecated methods. These deprecated methods have to be implemented, of course. If I compile my implementation I get deprecation warnings for these implemented methods. Does anyone know how I can get rid of these warnings? I've added @deprecated flags to my implementation of these methods, but that didn't solve these warnings. I'm using JDK 1.3.1.
Thanks
Daniel.

Technically it's a feature. :p
but seriously, the whole deprecated thing is a feature, it's too bad that in this case you have to live with it, but there's no way around it.
besides it doesn't matter if you call a depreciated method as it is still going to work. It just means that some point in the future it will not be supported. And judgeing by sun's past actions, I would say that it's more of a way to encourage people not to use old methods, but I don't think that they will ever remove the depreciated methods from the api.
The only methods you have to watch out for are the few like those the Thread which are just not implemented at all. Like thread.destroy()

File's Owner does not show methods in Interface Builder 3.2.6 but the class is set correctly and the nib on the lower left is green

Hi, I'm trying to make my first IPhone app. After having problems with interface builder the first time I coppied the code directly from a tutorial in case I made any mistakes. I saved the program, and re-opened the .xib file. Right clicking File's Owner does not show a list of methods. I've been looking around for solutions for this but have not gotten anything to work. I tried deleting the default .xib and creating a new one through file-> new file. This did not help. I did notice that File's owner was showing up as a light blue cube apposed to a yellow one now and found that a bit odd but otherwise nothing changed. I opened the library menu and selected helloWorldiPhoneViewController so it would show up in the view port. I set the class field of File's Owner to hellowWorldiPhoneViewController. File's Owner still does not show methods when right clicked or when a line is dragged over a button. I read somewhere that the color of nib on the lower left of the viewport may indicate a problem, but it is green not indicating any issue. Every solution I found for someone else seems nto to work for me and I don't know how to continue.
here is the .h file just in case:
// HelloWorldViewController.h
// HelloWorld
// Created by Paul Peelen on 2011-03-14.
// Copyright 2011 9697271014. All rights reserved.
#import <UIKit/UIKit.h>
@interface HelloWorldViewController : UIViewController {
UILabel *textLabel;
@property (nonatomic, retain) IBOutlet UILabel *textLabel;
- (IBAction)changeTheTextOfTheLabel;
@end
I'm trying to connect changeTheTextOfTheLabel to a button and textLabel to a label

You need a parameter for an interface builder method. The type should be id and the name is typically "sender". It would look like this:
- (IBAction)changeTheTextOfTheLabel: (id) sender;
Be careful about those tutorials. Many are ancient and do not correspond to current Xcode behaviour.

Abstract method in Interface

Why are we able to define abstract method in an Interface?
I don't imagine when I must use an abstact method in a interface.
Does anybody ever use this?

Thanks for your answer.
I can declare an abstract class which implementes an
interface.
The abstract class doesn't require the implementation
of the methods
declared in the interface.
Why this?Because the class is abstract.
A concrete class must provide (or inherit) implementations for all abstract methods in all its ancestor classes and for all methods in all interfaces it implements (and remember, all methods in an interface are abstract).
If a class does NOT have an implementation for one or more of those methods, the class must be declared abstract to indicate that.
I don't understand because an abstract class can
implements an interface!Any class can be declared abstract (except final classes, I think).
Any class that doesn't have implementations for all its methods (including those from interfaces) MUST be declared abstract.

Why not to use static methods in interfaces?

why?

Because static methods are always attached to a particular class -- not an object. So object polymorphism (which is what interfaces are good for) won't help. Now, what you can do is say that subclasses must implement a method that looks an awful lot like a static method, in that it doesn't depend on object state.
This bugged me, and it still bugs me a little bit in that I have to instantiate an object of a type in order to call these pseudo-static methods. When the pseudo-static methods tell the user how to initialize the object, you get a bit of a chicken-and-egg problem.

Static methods in interfaces

Java cognoscenti,
Anyone know why I can't declare a method as static in an interface, but I can in an abstract class. Surely, semantically it's the same - defering the implementation of a static method, not an abstract class and an interface. By the way, I'm using JDK 1.2.2 if that makes a difference

No, it's not the same. You are not "defering the
implementation of a static method" because static
methods are never polymorphic.
Static methods cannot be abstract for this reason, and
only abstract methods are allowed in interfaces.I didnt't know that. I thought that - because you can override static methods and you can call them onto an actual instance the method binding would be done at run-time, not at compile-time. So I was trying to prove you wrong, but you are correct !
A short summary of what I've learnt so far:
- interfaces cannot contain static methods
- abstract classes cannot contain abstract static methods
- static methods can be overriden, but they are not polymorphic; this means that the compiler decides which method to call at compile-time.
/* output
SuperClass.someMethod()
SubClass.someMethod()
SuperClass.someMethod()
SuperClass.someMethod()
SubClass.someMethod()
SubClass.someMethod()
SuperClass.someMethod()
public class Test {
public final static void main(String[] args) {
      // output: SuperClass.someMethod()
      new SuperClass().someMethod();
      // output: SubClass.someMethod()
      new SubClass().someMethod();
      // output: 2x SuperClass.someMethod()
      SuperClass someClass1 = new SubClass();
      someClass1.someMethod();
      showSuper(someClass1);
      // output: 2x SubClass.someMethod()
      SubClass someClass2 = new SubClass();
      someClass2.someMethod();
      showSub(someClass2);
      showSuper(someClass2); // SuperClass.someMethod()
public final static void showSuper(SuperClass c) {
        c.someMethod();
public final static void showSub(SubClass c) {
        c.someMethod();
class SuperClass {
public static void someMethod() {
    System.out.println("SuperClass.someMethod()");
class SubClass extends SuperClass {
public static void someMethod() {
    System.out.println("SubClass.someMethod()");

Optional methods in interface

Similar Messages

Maybe you are looking for