You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
General <strong>Java</strong> Questions I<br />
Q: I write java about 2 years, but I still confuse one thing that is why should we<br />
use interface???<br />
If I need to implement an interface and just use its every methods name.<br />
Why shouldn't just write every methods statments in a class, not in interface??<br />
I only can think about that if I extend a class, than can implement another or the<br />
others interface.<br />
As you can saw, I really confuse about this. And I do see many books for the reasons<br />
, but I can't get the answer, please tell me !<br />
Answer: "Interface" is the <strong>Java</strong> way to do multiple inheritance, or a better way to think<br />
of it is as a way to design plug-ins.<br />
For example, let's say we have an application that monitors a network of computers.<br />
Our monitors might check for web pages, or they may check for other ports, or they<br />
may have hooks for hardware checks.<br />
The interface to our main control panel is always the same: We need some means to<br />
poll the monitor object for an answer. This is the "NetworkMonitor" interface and all<br />
network monitors will share this interface, but they may have a class heirarchy that is<br />
very different, for example, port-monitors may all fork a thread that periodically<br />
checks whereas our control panel interface just asks for the most recent answer;<br />
hardware monitors may ask for their data in real-time or over RPC and thus have no<br />
need of inheriting from Thread.<br />
Because they share the same Interface definition, the control panel application does<br />
not need to know if they are polling monitors or real-time monitors because, from the<br />
control panel's point of view, it does not matter<br />
--<br />
...<br />
P.S. by John<br />
Also interfaces make our life (I mean programmers) much easier.<br />
Imagine a big project ( a lot of programmers, many packages, thousands of files): it is<br />
impossible all the time to be aware about particular implementation of some method<br />
in specific class in another package!<br />
Much easier to define interfaces between packages as some kind of bridges or gates<br />
into another package and their functionality, with hidden (for us) implementation. We<br />
just know interface and method names. It is enough to use those methods.<br />
How it is implemented there does no matter... It is working!<br />
Q: Is a static variables value likely to be garbage collected once objects of the<br />
class are no longer pointing to it? Does it destroy itself at any point or must that be<br />
done explicitly?<br />
I have a class with a static variable I create two instances of this class.<br />
In each instance I modify the static variable. Then I destroy the objects(point them to<br />
null), then create another instance of the same class and reference the static<br />
variable.<br />
Answer: No - the static variables are effectively linked to the Class object<br />
rather than any instances; they will only be garbage collected when the<br />
Class is garbage collected. This will only happen if the ClassLoader<br />
which loaded the Class is garbage collected.<br />
--<br />
Jon Skeet<br />
file:///F|/350_t/350_tips/general_java-I.htm (29 of 31) [2002-02-27 21:18:18]
Change language