Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

instantiate an interface???

Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in jave as far as i know that u cannot instantiate interfaces then how is it possible that DriverManager gives u a object of connection whereas connection is an interface and to be precise it is a public abstract interface.Please help me clear this doubt. thank you.
Ranch Hand
Posts: 547
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

whenever you have an interface specified as return value then
you do not receive an instance of that interface but you receive an instance of a class that implements this interface.

This is the same as with parameters: when your method expects a Connection you can pass everithing that implements this interface.

did that help ?

Ranch Hand
Posts: 268
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In a word, polymorphism. To understand this pillar of OOP (the other two are encapsulation and inheritance), you must get the difference between type and class. Fortunately, it's easy.

When an object is created, using the new operator, it is of a certain class. The class of an object is fixed for all time from its birth to when it's garbage collected. Objects cannot change their class. Another, very useful way to think about this is: Class is an *intrinsic* property of an object.

Type, on the other hand, is *extrinsic* to objects...that is, whereas class is an essential property of an object that's bound up with it no matter what, type is something that is conferred upon an object by the environment in which that object happens to find itself.

A ball's mass is intrinsic. It doesn't matter where a ball is, the mass is the same. A ball's weight is extrinsic. On Jupiter, a ball weighs less than on Earth. The environment of the ball determines its weight. Weight is extrinsic. A simpler example: a ball's elevation above sea level is extrinsic. If I'm in a boat with the ball, it's a few feet. If I'm on a mountain top, it's several thousand feet. The universe outside the ball determines its elevation, so elevation is extrinsic.

As such, as an object shows up in different parts of a software system, it can change type willy-nilly because type is extrinsic. It can even play the role of many types in the same block of code. Example:

In the above code sample, there are three objects created, all of class Bar. Each of these three objects is referred to by a named variable. The object that is the referent of "a" is of type Bar, because that's the type assigned to the reference "a". The object that is the referent of "b" is of type Foo, and "c" is of type Object. All three, at every point of their existence, however, are still of class Bar.

In the last block we see a single object have three references referring two it: a, a1, and a2. That object, still of class Bar, is now of all three types depending on the reference you use to access it. If you write: a1.method(), then the type that is conferred upon that object for the purpose of that particular method call is Foo. It can change from one call to the next.

You don't necessarily have to declare a reference to an object to change its time, either. If I were to write, based on the sample code above:

Then for the purposes of the objectMethod() call, the object in memory is of type Object. For the purposes of the barMethod() call, the object is of type Bar.

When a method returns an object, it need only declare the type of the object it's returning. In actuality, that object in memory may be of any class at all as long as that class can play the role of that type. (LinkedList can take on the types List, Collection, Object. HashMap can take on the types Map, Collection, Object. LinkedList can NOT be treated as type Map, nor can HashMap be treated as type List.)

There's only one other layer of complexity. Java provides the ability to create "anonymous classes":

This is the closest you can get to "instantiating an interface" directly. Strictly speaking, of course, you're not instantiating an interface, you're creating an unnamed class that implements that interface. This is akin to how the compiler actually interprets the above code block:

[ July 28, 2004: Message edited by: sever oon ]
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you get a return object called "retObj", do this:

System.out.println(retObj.getClass().getName()) ;

You will see that the returned object is actually an implementation class which implements the interface Connection.
What kind of corn soldier are you? And don't say "kernel" - that's only for this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic