This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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?
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.
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.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors