1

To address possible duplicates: I know what an interface is. I know how to implement them and all of that. I know what polymorphism is which allows the replacing of an object with a subtype. I know what abstract methods are, and I am not asking what any of these things are. Rather, I am asking what the point is for the inability to do what is so in the following question. Now to the question:

I have an interface. Let us call it Foo. It has the following abstract method:

public boolean isNumeric(Object o);

I also have a class Bar which implements Foo. It has the isNumeric method implemented like so:

public boolean isNumeric(DataPoint dp){

    //some stuff

    return true;
}

How come I cannot polymorph an abstract parameter? What is the point of the implementation of I can't be more specific?... Is that not part of the necessity of polymorphism. The allowance of going "down" a class and being able to be more specific to a particular case... it seems as though I cannot go backwards either; declare the parameter in the interface as a DataPoint and implement it as a Object.

Why can I not do so? Do I really have to cast it and then say in the Doc? "It has to be a DataPoint" bla bla bla? I can't just force it to be a data point in this case, and in another implementation be something else? If I have to cast I would have to handle the class cast exception and also counter the doc that defines the parameter which an explanation that says do not use "this parameter"... if that makes sense. It seems more work than the whole point of object oriented programming...

-Thanks

PS the questions are boldified.

JustAFellowCoder
  • 300
  • 2
  • 11
  • 2
    `isNumeric` in `Bar` is **not** overriding `Foo.isNumeric`. It's overloading it. – ernest_k Apr 12 '19 at 15:37
  • @ernest_k Is implementation technically an override... overloading would be for static methods... – JustAFellowCoder Apr 12 '19 at 15:38
  • 2
    That sounds like a bit of mixed up concepts. When you implement/override a method, you have to use the exact signature of the method (roughly speaking). The static thing is a completely different story. – ernest_k Apr 12 '19 at 15:41
  • @ernest_k So since I'm overriding, it does not count as implementing and all abstract methods must be implemented in concrete classes? Is this correct? – JustAFellowCoder Apr 12 '19 at 15:44
  • 1
    Since you're *overloading*. Yes. Concrete classes have to implement the abstract method from the interface. – ernest_k Apr 12 '19 at 15:45
  • @ernest_k So I have to have the Object version... even though I don't want that to be used because it won't do much of anything? I simply want to force it to have that method but not force it to be that specific data type, rather a subtype... possible? – JustAFellowCoder Apr 12 '19 at 15:50
  • You may want to look into making the method generic. – ernest_k Apr 12 '19 at 15:53
  • 1
    @JustAFellowCoder Since you have declared the method in interface `Foo`, any code with access to an object of a class implementing `Foo` can call the method, with any type of argument, e.g. `foo.isNumeric("Hello")`, so the `Bar` class must provide an implementation to define what happens when that call is made. – Andreas Apr 12 '19 at 15:53
  • @ernest_k Thank you thank you thank you. I used a generic for it allowed me to use any type if it matches when I implement the interface. Cheers bruthah. – JustAFellowCoder Apr 12 '19 at 16:10

1 Answers1

3

If Bar's isNumeric() is meant to override Foo's isNumeric() method, then for any Bar instance its isNumeric() will be used to serve any isNumeric() call. That's the basics of polymorphism.

Now imagine someone calling:

    Foo instance = new Bar();
    System.out.println(instance.isNumeric("Hello");

That's absolutely valid Java code. But your Bar.isNumeric(DataPoint) won't be able to handle that.

That's why you can't override a method if you change to more specific types in the subclass. You have to keep the parameter types.

Ralf Kleberhoff
  • 6,990
  • 1
  • 13
  • 7