Java – What’s the point of creating abstract classes from implementations without member variables?

This question is actually more specific than the topic, but I think the topic covers what I want to know.

I’m reviewing some code in a project that looks like something I want to use, and I see something that interests me because I’m not sure why I’m doing it. Specifically, in Chris Banes’ ActionBar-PullToRefresh, I saw this in .java:

package uk.co.senab.actionbarpulltorefresh.library;

import android.app.Activity;
import android.content.res.Configuration;
import android.view.View;

/**
* HeaderTransformers are what controls and update the Header View to reflect the current state
* of the pull-to-refresh interaction. They are responsible for showing and hiding the header
* view, as well as update the state.
*/
public abstract class HeaderTransformer {

/**
  * Called whether the header view has been inflated from the resources
 * defined in {@link Options#headerLayout}.
 *
 * @param activity The {@link android.app.Activity} that the header view is attached to.
 * @param headerView The inflated header view.
 */
public void onViewCreated(Activity activity, View headerView) {}

/**
 * Called when the header should be reset. You should update any child
 * views to reflect this.
 * <p/>
 * You should <strong>not</strong> change the visibility of the header
 * view.
 */
public void onReset() {}

/**
 * Called the user has pulled on the scrollable view.
 *
 * @param percentagePulled value between 0.0f and 1.0f depending on how far the
 *                         user has pulled.
 */
public void onPulled(float percentagePulled) {}

/**
 * Called when a refresh has begun. Theoretically this call is similar
 * to that provided from {@link uk.co.senab.actionbarpulltorefresh.library.listeners.OnRefreshListener} but is more suitable
 * for header view updates.
 */
public void onRefreshStarted() {}

/**
 * Called when a refresh can be initiated when the user ends the touch
 * event. This is only called when {@link Options#refreshOnUp} is set to
 * true.
 */
public void onReleaseToRefresh() {}

/**
 * Called when the current refresh has taken longer than the time
 * specified in {@link Options#refreshMinimizeDelay}.
 */
public void onRefreshMinimized() {}

/**
 * Called when the Header View should be made visible, usually with an animation.
 *
 * @return true if the visibility has changed.
 */
public abstract boolean showHeaderView();

/**
 * Called when the Header View should be made invisible, usually with an animation.
 *
 * @return true if the visibility has changed.
 */
public abstract boolean hideHeaderView();

/**
 * Called when the Activity's configuration has changed.
 *
 * @param activity The {@link android.app.Activity} that the header view is attached to.
 * @param newConfig New configuration.
 *
 * @see android.app.Activity#onConfigurationChanged(android.content.res.Configuration)
 */
public void onConfigurationChanged(Activity activity, Configuration newConfig) {}
}

My question with this file is, why make an abstract class here instead of an interface, or what is the purpose of making an abstract class? I see that the class has two abstract methods. My understanding is that abstract methods have to be defined in a subclass, otherwise that subclass is also an abstract class, right? So is this done as an abstract class so that only these two abstract methods are enforced? Is this the only reason to make abstract classes instead of interfaces here?

There can be many reasons for making it an abstract class, and you yourself pointed out some of them.

In this case, my guess is because it is a library.
Suppose you have a huge application and define many other classes using this class.

If you update the class by adding new methods, if it is an interface, your code will not compile because your code violates the “contract” of the interface (it does not implement all the methods). But in this case, it’s an abstract class that defines the default behavior: in this case, do nothing. This way your application does not break and compiles without problems.