text: Originally posted by Gregg Bolinger: So why is it not common practice to create class simply as a definition (Interface) and then implement that interface with another class.
  All java source files must end with the .java extension. A source file should generally contain, at most, one top-level public class definition; if a public class is present, the class name should match the unextended filename. For example, if a source file contains a public class called RayTraceApplet, then the file must be called RayTraceApplet.java. A source file may contain an unlimited number of non-public class definitions. NOTE: This is not actually a language requirement, but it is an implementation requirement of many compilers, including the reference compilers from Sun. It is therefore unwise to ignore this convention, because doing so limits the portability of your source files (but not, of course, your compiled files).
  What I do know is that if I create an interface and then implement that in a class, I am required to override it's public methods. Fine and dandy. But what point does it server me to define that method in an interface. Especially if I am not developing a library, for example.
  Originally posted by Eddie Vanda: Hi Greg, I am developing a client showing a number of different screens, each a different class, that all require refresh actions. Rather than compiling the specialised refreshing class to call each screen's class's timer handler separately, I get each screen class to register itself with the refresh handler class. The screen classes all implement the same interface for refresh but in completely different ways. The refresh handler class has a queue of objects of the type named by the interface and knows from the method declaration in the interface what method to call in each screen class. When I add another screen class I do not need to recompile the refresh handler class. The compiler reminds me if I have not implemented the method. Not sure if I have explained this too well, but it works for me. Ed
  Originally posted by Gregg Bolinger: And this is not the case with an interface? Why would a class that implements an interface not inheret all the data members of the interface?
  But what if down the road you realize you have to add a method to the interface, then you would still have to go to all your classes implementing that interface and override that method, right? True, adding OTHER implementations of Money would have been no problem. I assume the answer to this is just "That's programming."
  The problem I am having is the simple fact that just because you have an interface, you are still left with coding a lot of the same things over and over.
  So to take your example, say you had an interface called Money. Your methods don't really do anything.
  But what if down the road you realize you have to add a method to the interface, then you would still have to go to all your classes implementing that interface and override that method, right?
  Originally posted by sever oon: The point you bring up, though, about the "drawback" of interfaces is that if I write an interface and 100 people each write 20 classes that implement it, and then I go back and add another method to that interface, there are now 2000 classes that those 100 people have to update.