MVC View и AbstractView - почему оба? - PullRequest
Новая
       12

MVC View и AbstractView - почему оба?

1 голос
/ 10 сентября 2011

Я начинаю узнавать о приложениях, основанных на MVC, о том, что начинаю выполнять более сложную работу с JavaScript, и становится невыносимо просеивать спагетти-код для обновления. Я читаю главу Es'tial Actionscript 2.0 О'Рейли о паттерне MVC, поскольку слышал, что он довольно информативен. Вот быстрый вопрос, который у меня был:

В книге они настраивают представления, используя интерфейс View и конкретный класс с именем AbstractView. Класс AbstractView фактически реализует функции из интерфейса View плюс несколько помощников, но вам все равно придется создать свой собственный класс (ы) представления с дополнительной логикой, чтобы сделать что-нибудь полезное.

Итак, какой смысл создавать интерфейс View, единственное назначение которого - использовать его при создании объекта AbstractView? Далее они говорят, что для создания полезного представления для вашего приложения вам нужно создать собственный класс, который расширяет класс AbstractView. Разве это не делает ненужным наследование View / AbstractView?

Разве вам не нужен только один абстрактный класс View, который реализует базовые функции (как это делает AbstractView), а затем создавать свои собственные представления, которые наследуются от View? Я не вижу смысла в наличии интерфейса View и класса AbstractView, если вы никогда не собираетесь обходить класс AbstractView для наследования только от View.

Какие преимущества мне не хватает?

РЕДАКТИРОВАТЬ: Вот пример кода (ActionScript), который они используют: 

// -------------- 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 getModel ( ):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 {
  }
}

1 Ответ

1 голос
/ 10 сентября 2011

Хотя я могу не согласиться с соглашением об именах, на практике это имеет смысл, но на первом уровне у вас есть определение интерфейса, который необходимо реализовать. Не предоставляя ему никакой функциональности, он может быть реализован так, как вы хотите, никаких предположений не делается. В производном классе «AbstractView», как его называет О'Рейли (согласно вашему описанию), вероятно, разумным образом реализуются наиболее распространенные функции, но остается место для специализации. Некоторые инструменты обычно идут на шаг впереди, а затем дают простую полнофункциональную реализацию рассматриваемого класса.

Редактировать

Посмотрев на пример того, что Ксентил, я увидел еще одну причину такого разделения: AbstractView - это не , а просто , а также Observer. Таким образом, еще одна причина отделить базовую реализацию от Интерфейса состоит в том, чтобы не допустить реализации другой реализации интерфейса.

В общем, кажется, что они определяют абстрактные интерфейсы, которые могут быть составлены для классов более высокого порядка. Но интерфейс не загрязнен

  • реализация, и из этого предположения о функциональности
  • другой интерфейс

Таким образом, интерфейс View может использоваться без необходимости быть Observer и наоборот.

Кроме того, с языковой точки зрения, поскольку 'View' объявляет 'интерфейс' в Actionscript, он не может реализовывать какие-либо функции, он может содержать только определения, см. Adobe Docs . Другие языки, такие как c ++, не имеют ключевого слова interface и поэтому будут запускать другие подходы.

При разработке, если вы не применяете очень строгий подход, вы не можете пойти по этому пути, если вы не разрабатываете библиотеку много раз, есть только один класс, который будет реализовывать определенный интерфейс, у вас может даже не быть абстрактного интерфейса как показано здесь, но только конкретный класс. В конце концов, когда вам понадобится вторая или третья реализация объекта того же типа, вы извлечете интерфейс, вы можете смешать в нем некоторую реализацию или нет. Но они пытаются показать вам хорошие практики, чтобы, возможно, использовать их в демонстрационных целях.

Имеет ли это немного больше смысла?

...