Средства обеспечения MVC Вдохновленного продолжения Передачи стиль

Давайте начнем с простой вещью. blueBill Mobile содержит небольшое чтения RSS-канал, называемый «Новости», который используется для доставки сообщений пользователям из блога проекта. Требования просты:

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

Итак, давайте начнем с рассмотрения на UML диаграмме API:

Применяя стандартные образцы, у нас есть службы, обеспечивающих данные, MVC и класс один поддержки:

NewsService предоставляет два метода:

public interface NewsService
  {
    
    public void eventuallyCheckForUpdates();

    public void getNewsFeed (@Nonnull AvailabilityNotifier availabilityNotifier);
  }

Есть две характеристики getNewsFeed (), на которые мы должны обратить внимание:

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

Мы должны увидеть некоторые проблемы уже на этих помещениях. Например:

Но есть вопрос более тонкий. Рассматривая спецификации, давайте сосредоточимся на том, что сетевые подключения должны быть активированы посредством предпочтения, или система должна явно запросить подтверждение у пользователя. Давайте представим, как мы собираемся написать NewsViewController: он вызывает getNewsFeed () и, если он отвечает, что требуется сетевое соединение, открывает диалоговое окно подтверждения. Пользователь в конечном итоге подтверждает, что он хочет подключиться, и в этот момент NewViewController вызывает … что? Возможно, другой метод NewsService, такой как getNewsFeedWithoutConfirmation (), который подключается без запроса обратной связи.

Все в порядке? В конце концов , это будет работать , и я видел (и написано) много частей кода , как это. Проблема в том , что мешает рассеянно разработчика от прямого вызова getNewsFeedWithoutConfirmation (), таким образом , обходя любые проверки и нарушения спецификаций? Дело в том , что мы подвергнем методы в службе , которая не должно быть названа , но при точных предварительных условиях. Я думаю , что вы уже видели много раз, в JavaDocs, комментарии предупреждают, что «Этот метод НЕ НАЗВАТЬ ПОКА …». Конечно, многие не читают JavaDocs и, честно говоря, чаще всего такие предпосылки не должным образом задокументированы. Обычно это заканчивается тем , что много головной боли. Конечно, приложение должно быть проверено и правильно написанный тест обнаружит ошибку. Но надежный код навязываетполитика (для того, что возможно): предотвращение ошибок происходят по построению лучше, чем позволяют ошибке произойти и позже охоту на них.

С другой стороны, давайте проверим, правильно ли мы распределили обязанности между классами. Какой класс должен нести ответственность за соблюдение политики подтверждения соединения? Несомненно, NewsService, который инкапсулирует сетевое соединение; наверняка это не обязанность NewsViewController, которая должна только правильно координировать поток управления между NewsService и NewsView. Теперь в гипотетической реализации, которую мы нарисовали, ответственность распределяется между двумя классами: NewsService уведомляет о необходимости подтверждения (правильно), но NewsViewController способен напрямую загружать команду без дополнительного подтверждения. Вместо этого, он должен просто сообщить NewsService, что получил подтверждение (как получить подтверждение — это вопрос пользовательского интерфейса),и пусть последний решит, как продолжить (не вопрос пользовательского интерфейса).

Давайте попробуем лучший дизайн, чтобы справиться с проблемами, которые мы нашли до сих пор — для ясности, давайте вспомним их:

Принятие асинхронного стиля передачи сообщений является элегантным решением проблемы потоков. На практике мы гарантируем, что getNewsFeed () завершается немедленно, даже когда результат не готов; вызывающий будет уведомлен позже, с помощью обратного вызова, который передается в качестве аргумента:

    public static interface AvailabilityNotifier
      {
        public void notifyFeedAvailable (@Nonnull RssFeed newsFeed);

        public void notifyCachedFeedAvailable (@Nonnull RssFeed newsFeed);
        
        public void notifyFeedUnavailable();

        public void notifyFeedCouldBeDownloaded (@Nonnull DownloadConfirmation confirmation);
      }

AvailabilityNotifier будет вызываться в одном из четырех методов для одного из четырех возможных результатов:

Конечно, наличие определенного метода обратного вызова для каждого результата также устраняет необходимость переключения. Если версия будущего NewsService позволит пятый результат, наш код не будет компилироваться, если не обеспечить реализацию пятого метода, заставляя нас заботиться о новом поведении. Или, возможно, это будет возможно обеспечить реализацию по умолчанию нового метода (таким образом, превращая AvailabilityNotifier в абстрактный класс), чтобы иметь обратную совместимость с существующим кодом. Мы были бы безопасны в обоих случаях.

Теперь давайте сосредоточимся на четвертом методе notifyFeedCouldBeDownloaded (): это тот, который уведомляет о том, что данные могут быть загружены после подтверждения. Как видите, у него есть аргумент, называемый DownloadConfirmation. Это еще один обратный вызов:

    public static interface DownloadConfirmation
      {
        public void confirmDownload();
      }

Представленный единственный метод verifyDownload () позволяет завершить операцию (конечно, если пользователь отменяет операцию, метод не будет вызван). doDownload () снова работает асинхронно, возвращаясь немедленно (поэтому он может быть вызван потоком пользовательского интерфейса); Когда операция будет завершена с положительным или отрицательным результатом, начальный экземпляр AvailabilityNotifier будет уведомлен снова. Таким образом, вместо того, чтобы выставлять getNewsFeedWithoutConfirmation () в NewsService, предупреждая, что он не должен вызываться, но при некоторых обстоятельствах, метод verifyDownload () доступен только для объекта, который материализуется и, следовательно, может быть вызван, именно в этих обстоятельствах.

Давайте думать об этих обратных вызовах в качестве объектов, представляющих состояние в потоке управления приложением: каждое государство только предоставляет методы делать то, что разрешено делать в таком состоянии. Большое снижение шансов на ошибку.

Следует отметить, что реализация DownloadConfirmation может даже обеспечивать проверку в confirmDownload (), поэтому его можно назвать только один раз в случае (и, возможно, в течение определенного интервала времени). Это предотвратило бы трюки, такие как хранение ссылки на DownloadConfirmation вызвать confirmDownload () несколько раз во время других взаимодействий. Конечно, мы не можем автоматически обеспечивать надлежащее выполнение в NewsViewController (после того, как все это может просто делать вид, что пользователь подтвердил, не требуя ничего), но мы сделали некоторые разумные усилия, чтобы избежать некоторых тривиальных ошибок.

Ниже приведена схема API новостей, где вы можете увидеть отношения между классами, описанными до сих пор:

Теперь мы можем взглянуть на реализацию метода getNewsFeed () в NewsService (я не показываю полный список, но имена методов самоописываются):

    @Override
    public void getNewsFeed (final @Nonnull AvailabilityNotifier availabilityNotifier)
      {

        try
          {
            availabilityNotifier.notifyFeedAvailable(cache.getRssFeed());
          }
        catch (NotFoundException e)
          {
            ensureCacheIsInitialized(availabilityNotifier);
            
            if (!cache.getStatus().isDownloadNeeded())
              {
                readNewsFeedAndNotifyAvailability(availabilityNotifier);                    
              }
            else if (preferences.get().isNewsDownloadAllowed())
              {
                downloadNewsFeedAndNotifyAvailability(availabilityNotifier);
              }
            else
              {
                availabilityNotifier.notifyFeedCouldBeDownloaded(new DownloadConfirmation() 
                  {
                    public void confirmDownload() 
                      {
                        downloadNewsFeedAndNotifyAvailability(availabilityNotifier);
                      }
                  });
              }
          }
      }