Win a copy of Head First Agile this week in the Agile forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

To understand why some interface can work as an Object?  RSS feed

Kai Yang Tay
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I have been working on org.w3c.dom.* package.
And have been doing some development that is similar to

But I have a question that I am unable to understand.

I tried to read up on Java API page on Element, Document, Text, Node etc

But on the documentation page it shows that Element, Text and almost all things within this org.w3c.dom.* are interfaces.
As shown in the "Interface Summary".

So may I know why all this interface can become an similar to object characteristic and able to do the followings.

Element elment = doc.createElement(...);

why is that possible?

And I have met some problem (reasoning, not implementing yet) while trying to create a class to "extend" (i know it should be implement) all this interfaces? Because I will need all these createElement(..), appendChild(...) to be concrete, but from theory... interfaces shouldn't have any implementations in them at all...

So I am really confuse what is their purpose? how should they be used? how can i make use of them and extend them with some of my own implemented methods?

Thanks in advance.
Christophe Verré
Posts: 14691
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You need to study something about interfaces before going any further. If you'd try System.out.println(element.getClass()), you'll see that the element object is actually a concrete class which implements the Element interface. It is instanciated to a concrete implementation, somewhere in the createElement method.

You can read this tutorial about interfaces, and especially this chapter about using an interface as a type.
fred rosenberger
lowercase baba
Posts: 12542
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Imagine if I had a repairman business, where I hire workers. My contract with the workers states "anyone who works for FredCo will have a hammer, a screwdriver, and a wrench". When I hire someone, they sign my contract stating they will always have those three tools when they go out on a job. I hire plumbers, carpenters, and electricians. Carpenters might also carry a wood saw. Plumbers probably carry pipes and other fittings. Electricians might carry wire cutters.

I now advertise "All FredCo employees will always have a hammer, a wrench, and a screwdriver".

Now, a customer needs someone with a wrench. They call and says "I need a FredCo employee". They might get any of the three kinds of people I've hired - but they don't know or care which of the three types they get.

My employee shows up, and all the customer knows is that they've hired a FredCo employee. They tell her "use your wrench on this, your screwdriver on that, and your hammer on this other thing".

They don't ask my employee to "saw that board", because there is no guarantee that a FredCo employee has a saw.

that's basically how interfaces work. the interface file lists what methods a class must implement - it's the contract. When you say "class MyClass implements FredCo", MyClass is signing the contract stating they will have whatever methods the FredCo interface defines. MyClass is the employee.

Somewhere, the interface is published, stating what methods it's classes implement. this is the advertisement.

Some developer decides they need something that does what FredCo things can do. They ask for one, and get...something. The specific class type doesn't matter, they just refer to it as a FredCo type, and call the FredCo methods.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!