• Post Reply Bookmark Topic Watch Topic
  • New Topic

Problem trying to implement interface  RSS feed

 
Anders Gren
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let's say we have situation like this:

abstract class A

class B extends A

class C extends B

class D extends C implements SomeInterface


I'm trying to implement a method "doSomething" declared in SomeInterface in class D. While trying to call doSomething in main I get the error message ”The method doSomething is undefined for the type B”

This is my code i main:


I need container to be an object of type B, because it goes later into a list of type B. According to what I've been told, the only file I need to edit to make this work is class D.

Is my file structure right? Anything else a problem?
 
Paweł Baczyński
Bartender
Posts: 2083
44
Firefox Browser IntelliJ IDE Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
B does not define method doSomething() so you cannot call this method on a reference of type B. It does not matter that this reference refers to an object of type D that has this method.
If you really want to call this method and you are sure it is indeed an object of type D you can always cast it:

BTW, container does not to be declared as B to go into a list of B.

This works just fine:
 
Anders Gren
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was thinking about casting it like you suggest, but I was unsure about if it is best practice to use this solution?

When I later use this in my actual code B container = new D("1,2,3,4,5,6,7,8"); is already created in a list, and doSomething gets information about the two last parts in the string.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16059
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In general, you should avoid casting as much as possible.

When you do a cast, you are really circumventing the compiler's type checking. The type checking that the compiler does is a good thing, it helps you to write correct programs, so you don't want to deliberately circumvent the type checking unless there really is no other way to write the code.

A cast tells the compiler "I have this object here, and I know better than you what it is, so I want you to treat it as if it has this type". Java will still do a type check, but at runtime instead of at compile time. If, at runtime, it turns out that the object is not of the type that you specified, you'll get a ClassCastException. You can see that there are two disadvantages here: (1) normally you want to catch errors as early as possible, so having the check at compile time is better than having it at runtime, and (2) there's a small performance penalty, because the check has to be done while your program is running.

So, it's better to think how you can design your code in such a way that you don't need to cast. You could for example make class B implement SomeInterface, and if you don't want to provide an implementation of the doSomething() method in class B, then make classes B and C abstract (and implement the method in class D):

abstract class A

abstract class B extends A implements SomeInterface (but does not implement the doSomething() method)

abstract class C extends B (also does not implement the doSomething() method)

class D extends C (this one does implement the doSomething() method)

This way, this would work:
 
Anders Gren
Greenhorn
Posts: 7
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your help.
I like the friendly atmosphere here.
 
Javin Paul
Ranch Hand
Posts: 297
Eclipse IDE Firefox Browser Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is the reason why it's called "A friendly place for programming greenhorns!" :-)
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!