Martin Fowler — GUI Architectures. Часть 5

    Предыдущая часть здесь. Оригинал статьи здесь.

    Это последняя часть.

    Humble View (простое представление)


    Несколько лет назад в сфере программирования появилось новое модное веяние — писать самотестируемый код. Несмотря на то, что я являюсь последним человеком, к которому следует обращаться по вопросам моды, я целиком погрузился в эту идею. К тому же, среди моих коллег есть много фанатов xUnit каркасов, автоматических регрессионных тестов, методик Test-Driven Developement, Continious Integration и прочих подобных непонятных терминов.

    Считается, что одной из проблем написания самотестируемого кода является написание тестов к пользовательским интерфейсам. Многие люди думают, что тестирование GUI по уровню сложности находится где-то между «очень сложно» и «невозможно». Такая оценка происходит из того, что пользовательские интерфейсы тесно связаны с общей средой UI и поэтому их сложно выделить в одно целое и протестировать по кусочкам.

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

    Решением описанной проблемы является такой дизайн пользовательских интерфейсов, где минимизируется количество функционала для труднотестируемых объектов. Этот подход четко описал Michael Feathers в своей работе The Humble Dialog Box. Gerard Meszaros обобщает это понимание в идею простого объекта (Humble Object) — любой объект, который сложно протестировать, должен обладать минимумом функционала. Тем самым, если нам не удастся создать тесты для такого объекта, шансы получить ошибку в его поведении так же минимизируются.

    В работе The Humble Dialog Box используется presenter из модели MVP. Однако, он обладает гораздо большими возможностями, чем тот, что описан в базовом MVP. Presenter не только определяет, как реагировать на события, но и занимается наполнением данными в пользовательских элементах. В результате, получается, что пользовательским элементам больше нет нужды иметь доступ и обозревать модель. Они формируют пассивное представление (Passive View), которое целиком управляется через presenter.

    Описанный подход не единственный, которым можно сделать представление простым. Другой подход — использовать шаблон модели представления (Presentation Model). Его маленьким минусом является то, что элементам управления нужно будет придать больше функционала, который позволит им привязаться (map) к модели представления.

    Ключем в обоих подходах является то, что тесты приходится писать только для presenter-а или модели представления. В них тестируется основной «рисковый» функционал, а сами «сложнотестируемые» элементы управления остаются в стороне.

    Подробнее о модели представления. Модель представления должна реализовывать всю значимую логику. Все пользовательские события должны перенаправляться в модель представления. Все, что нужно сделать элементам управления — это привязаться к ее соответствующим свойствам. Тесты будут тестировать весь функционал модели представления без необходимости присутствия какого-либо элемента управления. Единственный риск остается только в самой привязке элементов к модели. Если учесть, что функционал привязки очень прост в реализации, можно закрыть его тестирование глаза. Правда, в этом случае, представление не такое «простое», как могло бы быть в подходе Passive View. Однако, разница очень мала.

    В случае с пассивным представлением (Passive View), как я уже сказал, отсутствие функционала привязки убирает риск, который присутствует в случае с моделью представления. Цена отсутствия этого риска заключается в необходимости двойного тестирования (Test Double), которое нужно, чтобы проэмулировать поведение экрана во время выполнения тестов. Это значит, что нужно будет создавать и настраивать какой-то дополнительный программный механизм.

    Похожее решение присутствует и в шаблоне Supervising Controller. Некоторый риск возникновения ошибки возникает тогда, когда представление вынуждено заниматься привязкой (как в случае с моделью представления (Presentation Model). Преимущество такой привязки, кстати, состоит в том, что вся она является декларативной. Количество таких привязок при Supervising Controller будет меньше, чем в модели представления, поскольку Supervising Controller занимается передачей данных (в самых сложных случаях и сценариях) к элементам управления в явном виде, определенном в его коде, тогда как модель представления вынуждена решать свои сложные сценарии через механизм привязок.

    Далее


    Если вы хотите прочитать статьи, в которых развиваются описанные идеи, проверьте мой bliki

    Благодарности


    Василий Быков щедро поделился со мной своей копией Hobbes — имплементацией платформы Smalltalk 80 версии 2 (1980 годы!), которую можно запустить на современной версии VisualWorks. В этой копии я смог создать примеры на живом, оригинальном MVC, что мне очень помогло понять, как он работал и использовался в те времена. Кстати, много людей негативно воспринимают использование виртуальных машин. Интересно, чтобы они сказали, если бы увидели, как я работаю в Smalltalk 80 на виртуальной машине, написанной в VisualWorks, которая работает на виртуальной машине VisualWorks, которая работает на Windows XP, которая запущена в VMware, которая запущена в Ubuntu?

    Значительные редакции


    18-ое июля 2006 года: первая публикация на сайте

    Все права принадлежат Мартину Фаулеру (Martin Fowler). Все права защищены.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 17

      +3
      Молодец продолжай дальше, а то совсем «апопсовел» habrahabr.
        0
        Какая замечательная шиза, переводи её и дальше. Наткнулся на твой блог, потому что увидел как бармалейкина от чего-то блюёт и кидает, значит надо брать :)

        Накидал схемку (http://pic.ipicture.ru/uploads/090311/WQDt1NDSSV.jpg), юзать теперь буду эту технику, а то руки обычно до этого не доходили. В отличие от явы и прочих, дотнетина использует модель документ-вид. Хоть MVP в ней применить и то как говорится хлеб.

        А вообще, если меня спросят, зачем я вместо того чтобы набросать гуёвым дизайнером формочки накатал кучу классов и пытаюсь управлять всем вручную, то отвечу просто, — «Я так вижу!!!».
          0
          «Набрасывание гуёвым дизайнером формочек» совсем не противоречит «накатыванию кучи классов». В частности в VisualWorks, упоминающемся в предыдущих частях этой статьи, очень грамотный и удобный дизайнер формочек. А результат его работы — нормальные классы, созданные в парадигме Application Model, с которыми можно дальше спокойно работать — причём как изменяя их вручную, так и через дизайнер формочек.

          А зачем — так затем, что с кодом работать (изменять его, рефакторить и т.д.) гораздо проще, чем с внутренним форматом некого дизайнера формочек. Или вы создаёте приложения раз и навсегда, никак не меняя их в дальнейшем?
            –1
            Я не работаю с VisualWorks и никогда работать не буду, мне даже не интересно что это за фиговина. И вообще не вижу смысла связывать парадигмы программирования (http://ru.wikipedia.org/wiki/Категория: Парадигмы_программирования) и конкретные ограниченные реализации каких-то там систем. Все эти статьи об общих принципах программирования.
              0
              Это называется "пример".
                0
                Это называется тем, что ты не понимаешь для чего это вообще пишут. Не зря тут выше сказали, что хабр это попсовая тусовка.

                «Паради́гма (от греч. παράδειγμα, «пример, модель, образец») — универсальный метод принятия эволюционных решений, ментальная модель мира и мироустройства, основанная на сформировавшихся идеях, взглядах и понятиях.»

                А ты всё свёл к банальному слону, которым сам похоже пользуешься или просто слышал, что дескать это круто.
                  0
                  Я не кормлю троллей, ешь в другом месте.
                    0
                    Думаешь от того, что обозвал меня троллем стал умнее? За собой лучше следи.
                    0
                    Извините. но про политику у Вас зажигательнее получается. Замечание о том, что вы не хотите связывать теорию и практику ставит под вопрос вашу квалификацию как программиста :)

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

                    >>которым сам похоже пользуешься
                    Если вы решите мне ответить по существу, попрошу не «тыкать». Спасибо.
                      0
                      >Замечание о том, что вы не хотите связывать теорию и практику ставит под вопрос вашу квалификацию как программиста :)

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

                      А практика здесь ни причём. Я практикуюсь на разных конкретных системах, что мне толку смотреть ещё одну. Именно потому мне и интересны абстракции стоящие над моими мыслями во время использования конкретики.

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

                      Всё дело в используемой парадигме, ментальной модели преобразующий мысли в проект программы, а потом и в код.
                        0
                        Ясно. В таком случае или я вас не понял в предыдущем посте, или вы говорите совершенно противоположную вещь. Мне казалось, вы утверждали что парадигма не меняется от реализации к реализации, но ее можно конкретно испортить этой самой реализацией, если оная корява.

                        Ваши мысли насчет квалификации и мне близки.

                          0
                          >Мне казалось, вы утверждали что парадигма не меняется от реализации к реализации

                          Так надо сразу определиться с понятиями.

                          Парадигма программирования — это ментальная модель мышления программиста во время написания программы. Более того, один программист может пользоваться разными ментальными моделями.

                          Система программирования — это набор инструментов позволяющих создать программу. Это могут быть IDE, компиляторы, линковщики, дизайнеры кода, библиотеки алгоритмов и всё что угодно.

                          Программа — это набор поручений исполнителю, в нашем случае компьютеру. Для её создания мы можем использовать разные парадигмы программирования и разные системы программирования.

                          Реализация программы — это конкретные данные созданные с помощью определённой парадигмы программирования и на определённой системе программирования.

                          Причём в настоящее время системы программирования столь мощны, что не ограничивают программиста в парадигмах программирования. Хочешь делай так, а хочешь иначе.

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

                          Но вот незадача, программист часто привыкает к той парадигме, в которой написаны библиотеки, которыми он пользуется. Или ещё хуже, он пишет как умеет и при этом умеет он скажем так не важно.

                          Эти статьи помогают взглянуть на процесс программирования с разных точек зрения. А потом приходит какой-нибудь человек и заявляет, а мой слон (система программирования) самый слонистый слон, он умеет становится на задние ноги.
                            0
                            Я так долго и красиво говорить и копипастить не умею, извините :)

                            Отвечу проще — тут дело не в «самом слонистом», а в некотором Abstract Slon, который суть есть парадигма. Поняв его, можно понять любого отдельно взятого Concreete Slon.

                            В данном случае в качестве Abstract Slon выступает MVC. А Visual Works — просто как доказательство того, что MVC а) существует б) может быть изменено и улучшено для удобства программиста

                            Хм, наверное, лучше нас автор рассудит.
                              0
                              Фаулер чтоли?:)
                                0
                                У него не допросишься — страшно занятой субъект :)

                                Я имел в виду, что желания спорить нет, пусть каждый думает так, как он думает, а автор (переводчик т.е.) — как он написал :)
                                0
                                >Я так долго и красиво говорить и копипастить не умею, извините :)

                                В том то и дело, что то, что пишу я, это не копипаста :) Я движусь от конкретного к абстрактному и вывожу улучшенные определения.

                                Concreete Slon как и Concreete Slons это пройденный этап. Мне просто уже не интересно мыслить в данных категориях.

                                >Хм, наверное, лучше нас автор рассудит.

                                Хорошие книги по программированию можно читать и читать, и каждый раз будешь находить что-то новое. Их восприятие обычно идёт в меру своей ограниченности.
              0
              спасибо за все параграфы!

              Only users with full accounts can post comments. Log in, please.