MVC View and AbstractView - why both?

I'm starting to learn about MVC-based applications being that I'm getting into some heavier JavaScript work and it's becoming unbearable to sift through spaghetti code to update things. I'm reading through O'Reilly's Essential Actionscript 2.0 chapter on the MVC pattern as I've heard that it's pretty informative. Here's a quick question that I had:

In the book they setup the views using a View interface and a concrete class called AbstractView. The AbstractView class actually implements the functions from the View interface plus a few helpers, but you'd still have to create your own custom view class(es) with additional logic to do anything useful.

So, what is the point of creating a View interface, whose only purpose is to be used when an AbstractView object is instantiated? They go on to say that to actually create a usable view for your application, you'd need to create your custom class that extends the AbstractView class. Doesn't this make the View/AbstractView inheritance unnecessary?

Shouldn't you just have one abstract class, View, that implements the basic functions (as AbstractView does), and then create your custom views that inherit from View? I don't see the reasoning behind having a View interface and an AbstractView class if you're never going to bypass the AbstractView class to only inherit from View.

What benefit(s) am I missing?

EDIT: Here's the (ActionScript) sample code that they use:

// -------------- View Class --------------
interface mvc.View {
  // Sets the model this view is observing.
  public function setModel (m:Observable):Void;

  // Returns the model this view is observing.
  public function getModel ( ):Observable;

  // Sets the controller for this view.
  public function setController (c:Controller):Void;

  // Returns this view's controller.
  public function getController ( ):Controller;

  // Returns the default controller for this view.
  public function defaultController (model:Observable):Controller;
}

// -------------- AbstractView Class --------------
class mvc.AbstractView implements Observer, View {
  private var model:Observable;       // A reference to the model.
  private var controller:Controller;  // A reference to the controller.

  public function AbstractView (m:Observable, c:Controller) {
    setModel(m);

    if (c !== undefined) {
      setController(c);
    }
  }

  // Returns the default controller for this view.
  public function defaultController (model:Observable):Controller {
    return null;
  }

   // Sets the model this view is observing.
  public function setModel (m:Observable):Void {
    model = m;
  }

   // Returns the model this view is observing.
  public function g开发者_如何学运维etModel ( ):Observable {
    return model;
  }

   // Sets the controller for this view.
  public function setController (c:Controller):Void {
    controller = c;

    // Tell the controller this object is its view.
    getController( ).setView(this);
  }

   // Returns this view's controller.
  public function getController ( ):Controller {
    if (controller === undefined) {
      setController(defaultController(getModel( )));
    }

    return controller;
  }

  public function update(o:Observable, infoObj:Object):Void {
  }
}

While I might not agree with the naming convention, in practice it does make sense, in the first level you have the definition of the interface that needs to be implemented. In not giving it any functionality it can be implemented any way you want, there are no assumptions being made. In the derived class 'AbstractView' as O'Reilly calls it (per your description) probably implements the most common functions in a reasonable way, but leaves room for specialisation. Some toolkit usually go one step further and then give you a simple fully functional implementation of the class in question.

Edit

After looking at the example that Xenthyl, i saw another reason for this separation, the AbstractView is not just a view it is also an Observer. So another reason to separate the base implementation from the Interface is too keep another interfaces implementation out of it.

In general what they seem to be doing is defining abstract interfaces that can be composed to higher order classes. But the interface is not polluted with

• an implementation, and from that an assumption of functionality
• another interface

This way the View interface can be used without having to be an Observer and vice versa.

Also from the language point of view as the 'View' is declare an 'interface' in Actionscript it cannot implement any functions, it can only contain definitions, see adobe docs. Other languages like c++ don't have the interface keyword and therefore will trigger different approaches.

When developing, unless you apply a very strict approach you might not go that route, unless you are developing a library a lot of times there is only one class that will implement a certain interface, you might not even have the abstract interface as it is shown here but just the concrete class. Eventually when you need a second or third implementation of the same type of object you would extract an interface, you might mix some implementation in it, or not. But they are trying to show you good practices so they are possibly overengineering things for demonstration purposes.

Does this make a little bit more sense ?