*
The moose likes Beginning Java and the fly likes Why does this work? (apparent creation of an instance of an interface) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Why does this work? (apparent creation of an instance of an interface)" Watch "Why does this work? (apparent creation of an instance of an interface)" New topic
Author

Why does this work? (apparent creation of an instance of an interface)

Mike Smithson
Greenhorn

Joined: Sep 15, 2011
Posts: 14
My first post!

I am an intermediate-level programmer at best (passed SCJA and studying for SCJP)... I am looking at some code at work that is confusing the heck out of me, it appears that it is creating an instance of an interface and then calling interface methods (that i can't find the implementation for).

This is the line that is confusing me:


eUser is argument to the method as an interface type as well (iEuser eUser).

So it appears to me that eMember is being created via a cast of an IUser interface to an IMember interface.

But a few lines later, methods are being called that are defined in the IMember interface (via eMember.getThisInfo() references [example syntax]).

I can't figure out where the implementation for getThisInfo() is, I can see the abstract method declaration in the interface but how is it getting implemented?

Any hints as to what I'm not reading right??

Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

It's perfectly legitimate to have variables of an interface type. In fact that's basically the whole reason behind an interface, that you can assign an object which implements an interface type to a variable of that type.

Which is what is happening in that code.

As for "where the implementation for getThisInfo() is", the implementation is in whatever class the object referred to by "eUser" belongs to. All we know from that code is that it's some class which implements IMember, and that's all you need to know.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37900
    
  22
Welcome to the Ranch
Mike Smithson
Greenhorn

Joined: Sep 15, 2011
Posts: 14
Campbell, thanks for the welcome!

I'm still trying to wrap my head around Paul's response. It is kind of a mind warp for me, I'd drilled into my head that you can't create an instance of an interface, but I sort of understand what he's saying.

I'm going to try to trace back to getThisInfo()'s implementation as I need to understand something about the data that's being returned.

Thanks again!
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Have you got to the part of your course where you learn that variables are not objects? That should be made very clear as soon as you start learning about objects, but for some reason either the books don't print it in boldface capital letters or the readers go right past without understanding its relevance.

So. A variable is not an object. A variable may contain a reference to an object (or it may contain null). An object may indeed not be an object whose class is an interface type. (That is the rule you refer to.) But a variable may be a variable of an interface type. And if it is, if it isn't null, it must contain a reference to an object of some class which implements that interface. Such an object is not an instance of the interface, it is an instance of the class which implements the interface.
Ove Lindström
Ranch Hand

Joined: Mar 10, 2008
Posts: 326

Think like this Mike.

You are and always will be Mike. From my view, here on JavaRanch, you are implementing the interface IJavaProgrammer that defines methods that I can call on to get you to write Java code.

When you go home, a friend calls you and ask you to help him move some stuff, since you have a car and is a licensholder. You are implementing the interface ICarOwner and IDriverLicensHolder. You are still the same Mike and I don't really care about what other interfaces you are implementing, as long as I can call your implementations of the IJavaProgrammer interface.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37900
    
  22
Find my old Engine interface. It looks like this:. . . but should really have some /** comments */ to give a description of the methods. Now you can write a factory method which creates an object of that interface. Note you cannot add a constructor to one version because it is in anonymous class format:The first type gives some sort of plausible number of gallons used at so many mph, but is very very economical at 25mph. It is a method-local class. The second is an anonymous class. Those are two of the ways you can get it to work. and if you don't believe it is possible, run this class:Obviously you can play with that code. I edited it to take out a spelling error in the last class.
Ove Lindström
Ranch Hand

Joined: Mar 10, 2008
Posts: 326

Nice example Campbell!
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37900
    
  22
Thank you

I have found an old post with what appears to be the same Engine interface in, but that version has the documentation comments.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

Mike Smithson wrote:So it appears to me that eMember is being created via a cast of an IUser interface to an IMember interface.

No, casting does not create an instance of anything. The only way to create new objects is by using the new operator. If you don't see the new operator in a line of code, then no instance is created in that line of code. (You can also create new objects by deserializing them, but that's a special exception to the rule).

The only thing that a cast does, is tell the compiler "look, I have this object here, and I want you to treat it as if it is of type IMember".

Casting (of reference types) does not create new objects or do any special conversions.

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37900
    
  22
Jesper de Jong wrote: . . . The only thing that a cast does, is tell the compiler "look, I have this object here, and I want you to treat it as if it is of type IMember". . . .
. . . with the complication that at Runtime, you may be mistaken about its being an IMember, in which case you see one of these
Mike Smithson
Greenhorn

Joined: Sep 15, 2011
Posts: 14
Campbell Ritchie wrote:
Jesper de Jong wrote: . . . The only thing that a cast does, is tell the compiler "look, I have this object here, and I want you to treat it as if it is of type IMember". . . .
. . . with the complication that at Runtime, you may be mistaken about its being an IMember, in which case you see one of these



Campbell - funny you should point that out, as that is exactly what is happening in our code! :-) I basically know WHY the ClassCastException is happening, I was just struggling with the code where it happens.. Lots of good information above that I'm digesting still, thanks guys!

FYI, this is for a production issue I'm looking at for my day job, not for a course or my SCJP prep work (using Sierra/Bates primarily for that)... but obviously i am also interested in learning for SCJP as well!
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 37900
    
  22
Class casts are nasty evil things. They are error-prone and should be avoided as much as possible.
I pointed it out because I have had so many myself

You need to decide what is being returned, and what you want.
  • How do you get eUser?
  • Does its class implement the IMember interface? (By the way, it looks more like C# coding conventions than Java™, starting interface names with I.)
  • What is the return type of the method you get eUser from?
  • What methods are there in the IMember interface?
  • Do you need any more methods?
  • Mike Smithson
    Greenhorn

    Joined: Sep 15, 2011
    Posts: 14
    Campbell Ritchie wrote:Class casts are nasty evil things. They are error-prone and should be avoided as much as possible.
    I pointed it out because I have had so many myself

    You need to decide what is being returned, and what you want.
  • How do you get eUser?
  • Does its class implement the IMember interface? (By the way, it looks more like C# coding conventions than Java™, starting interface names with I.)
  • What is the return type of the method you get eUser from?
  • What methods are there in the IMember interface?
  • Do you need any more methods?


  • eUser is passed to the method:



    I have no idea where the coding convention in play came from.. it's code from part of a very large enterprise site's login process, over which i have little control.. Essentially what is happening is that this particular code is getting hit for all different login user roles, and the class cast exception happens whenever it's not a "Member" role.. I think I know how to fix, but really want to understand it all both from perspective of my fix code and also my general knowledge, in that i hate feeling like I don't fully understand something! lol.. plus i know i have to understand it for SCJP of course...


    IMember actually extends IEUser, as do our other user roles...

    I have to figure out what eUser is when it comes in, if not a member, don't do the cast (and skip the few lines of Member-specific code directly below).. seems simple enough, it just bugs me that I didn't fully understand it all.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 37900
        
      22
    If IMember extends IEUser, then you can cast an IMember to IEUser (though it is unnecessary) but it may not be possible to cast an IEUser to IMember.

    You can do an if (eUser instanceof IMember) ((IMember)eUser).something(); check, in which case the cast is possible, but that will miss out eUser objects which don't implement IMember. Note the poor style of that code snippet without {}.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Why does this work? (apparent creation of an instance of an interface)
     
    Similar Threads
    Difference between low coupling and encapsulation
    HttpSessionBindingListener vs HttpSessionListener
    Expanding an application for multiple clients
    Abstract classes ?
    interface and implementation