【转】Abstract class vs interface

Q: In Java, under what circumstances would you use abstractclasses instead of interfaces? When you declare a method asabstract, can other nonabstract methods access it? In general,could you explain what abstract classes are and when you might usethem?

A: Yes, other nonabstract methods can access a method that youdeclare as abstract.

But first, let's look at when to use normal class definitionsand when to use interfaces. Then I'll tackle abstractclasses.

Class vs. interface

Some say you should define all classes in terms of interfaces,but I think recommendation seems a bit extreme. I use interfaceswhen I see that something in my design will changefrequently.

For example, the Strategy pattern lets you swap new algorithmsand processes into your program without altering the objects thatuse them. A media player might know how to play CDs, MP3s, and wavfiles. Of course, you don't want to hardcode those playbackalgorithms into the player; that will make it difficult to add anew format like AVI. Furthermore, your code will be littered withuseless case statements. And to add insult to injury, you will needto update those case statements each time you add a new algorithm.All in all, this is not a very object-oriented way toprogram.

With the Strategy pattern, you can simply encapsulate thealgorithm behind an object. If you do that, you can provide newmedia plug-ins at any time. Let's call the plug-in classMediaStrategy. That object would have one method: playStream(Streams). So to add a new algorithm, we simply extend our algorithmclass. Now, when the program encounters the new media type, itsimply delegates the playing of the stream to our media strategy.Of course, you'll need some plumbing to properly instantiate thealgorithm strategies you will need.

This is an excellent place to use an interface. We've used theStrategy pattern, which clearly indicates a place in the designthat will change. Thus, you should define the strategy as aninterface. You should generally favor interfaces over inheritancewhen you want an object to have a certain type; in this case,MediaStrategy. Relying on inheritance for type identity isdangerous; it locks you into a particular inheritance hierarchy.Java doesn't allow multiple inheritance, so you can't extendsomething that gives you a useful implementation or more typeidentity.

Interface vs. abstract class

Choosing interfaces and abstract classes is not an either/orproposition. If you need to change your design, make it aninterface. However, you may have abstract classes that provide somedefault behavior. Abstract classes are excellent candidates insideof application frameworks.

Abstract classes let you define some behaviors; they forceyour subclasses to provide others. For example, if you have anapplication framework, an abstract class may provide defaultservices such as event and message handling. Those services allowyour application to plug in to your application framework. However,there is some application-specific functionality that only yourapplication can perform. Such functionality might include startupand shutdown tasks, which are often application-dependent. Soinstead of trying to define that behavior itself, the abstract baseclass can declare abstract shutdown and startup methods. The baseclass knows that it needs those methods, but an abstract class letsyour class admit that it doesn't know how to perform those actions;it only knows that it must initiate the actions. When it is time tostart up, the abstract class can call the startup method. When thebase class calls this method, Java calls the method defined by thechild class.

Many developers forget that a class that defines an abstractmethod can call that method as well. Abstract classes are anexcellent way to create planned inheritance hierarchies. They'realso a good choice for nonleaf classes in class hierarchies.

原文：http://www.javaworld.com/article/2077421/learn-java/abstract-classes-vs-interfaces.html