The most confusing (might not be the most difficult) of the OO part for SCJA objectives for me is this principle. I searched for it everywhere, but couldn't understand it properly. Finally, when I took the reference of "Head First Design Patterns", I have started understanding it now. As per the rules of the forum, I can't present that paragraph here. You can refer to that book. Thanks.
Swapnil S. Sonawane<br /> <br />B.Tech (Expected May 2009)<br />Computer Science, NIT Durgapur, India<br />SCJA 1.0
I will take the title of the post as being the question.
The title is sufficient to understand your question.
An interface, something with you may write or others may write, specifies what a program may be expected to do - though one may not 'instantiate' an interface.
How is this possible? One writes a class that implements an interface. You may write that class, others may have written it. The implementation of the interface delivers what the interface says it will. The code delares an 'instantiation' of a class that implements an interface. The code then may call the methods described in the interface in the expectation that it will do what it says.
If the impelmentation does not deliver as promised, the implementation is defective.
"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
This is one of the topics that seems to intimidate SCJA candidates the most. This is understandable, as the true value of interfaces doesn't always become apparent until you have been on a large project or two, something many SCJA candidates are only just getting into. However, driving home the value of using interfaces is extremely important, as it will help you develop and design better applications over time.
Your respect for copyright is commendable. It really discourages authors when they see their work reproduced and uncredited. Having said that, here's a little snippet from the SCJA Certification Guide about the Programming to an Interface objective. I'm pretty tight with the author of the Guide, so I'm sure he won't mind this reproduction of his work.
When developing code, it�s important to make your code as flexible as possible. One way to make your code incredibly flexible and pluggable is to define instance variables and method parameters using the least specific, or most general, type of object you could imagine.
If you define method parameters that take a very general interface or abstract class as an argument, other developers have the flexibility to pass into your method any class that functionally implements the requirements of that interface or abstract class.
The same thing goes for instance variables as well. Defining instance variables at a very general level, and then allowing those instance variables to be initialized with more specific, concrete objects at runtime, makes your code, and your applications, much more flexible.
When defining instance variables, or figuring out what types of objects to pass as arguments to a method, always chose the most generic type you can, so long as that generic object provides the functionality your application requires. In Java, the most general 'type' is an interface, so as they say, always try to 'program to an interface.'
Kindest regards, and best of luck on your studies!
Joined: Jan 02, 2008
Thanks a lot. That helped too. I think I know this author.
subject: Program to an interface, not implementation