Всякий раз, включая компьютер, вы имеете дело с пользовательским интерфейсом (User Interface, UI), который кажется простым и очевидным, но, чтобы он стал таким, в индустрии было вложено немало труда. Оглянемся на 1990-е годы, когда настольные компьютеры стали повсеместными, и приведем хронологию развития технологий UI. Рассмотрим также, как развивались средства программирования UI и что они собой представляют сегодня. В табл. 1 приведен перечень основных задач разработки UI, на базе которых проводился анализ различных технологий реализации пользовательских интерфейсов, распределенных по категориям. Каждая из этих категорий включает технологии, решающие одну или более задач примерно одинаковыми способами.
Одну из главных категорий средств разработки UI образуют инструментарии, ориентированные на формы ввода данных с привязкой к реляционным СУБД. Суть данного подхода состоит в создании UI для приложений путем построения форм, отображающих значения полей базы в соответствующих элементах управления: текстовых полях, списках, кнопках-флажках, таблицах и т. п. Инструментарий позволяет выполнять навигацию по такой форме и устанавливать прямую связь между элементами управления и данными в базе. Разработчику не нужно заботиться о блокировках, передаче, преобразовании и обновлении данных - когда пользователь, например, переключает номер записи в форме, ее остальные поля обновляются автоматически. Аналогично, если пользователь меняет значение в поле, привязанном к какой-либо записи из базы, это изменение мгновенно в ней сохраняется. Чтобы добиться этого, не нужно специально писать код - достаточно задекларировать привязку элемента управления или всей формы к источнику данных. Таким образом, поддержка привязки к данным в инструментах этой категории - одна из сильных сторон данного метода. Задачи планировки и стилизации UI в таких средах решаются с помощью дизайнеров форм и специализированных объектно-ориентированных API. Для управления поведением UI обычно предлагаются обработчики событий (представляющие собой методы, реализованные на основном языке программирования среды разработки), тогда как для контроля вводимых значений используются выражения (в том числе регулярные). Типичные представители этой многочисленной категории инструментариев - Microsoft Access и Oracle Forms.
Технологии построения пользовательских интерфейсов на базе шаблонов, реализованных на языках разметки, начали повсеместно применяться с середины 1990-х. Основные преимущества шаблонов - гибкость и широта возможностей создания динамических пользовательских веб-интерфейсов, особенно с точки зрения разработки структуры и планировки. Вначале в таких инструментариях использовались шаблоны, в которых планировка и структура UI задавались с помощью языка разметки, а привязка к данным осуществлялась с помощью небольших блоков на языке высокого уровня (Java, C#, PHP, Python и т. д.). Последние могли использоваться в комбинации с разметкой; например, путем внедрения тегов разметки в цикл на Java могли создаваться итеративные визуальные элементы наподобие таблиц и списков. Необходимость частой смены синтаксиса внутри веб-страницы затрудняла разработку и коррекцию кода для программистов, поэтому около десяти лет назад начался переход с языков высокого уровня на специализированные библиотеки тегов разметки и языки выражений, созданные для конкретных веб-технологий.
Теги разметки стали использовать для реализации типовых функций веб-приложений, а выражения - для доступа к данным и вызова функций, хранимых в серверных объектах. Типичный представитель этой группы - технология JavaServer Pages (JSP), библиотека тегов которой JSP Standard Tag Library поддерживает такие задачи, как: манипуляция с XML-документами, циклы, условия, опрос СУБД (привязка к данным) и интернационализация (форматирование данных). Язык выражений JSP - EL, служащий средством привязки к данным, предлагает удобную нотацию для работы с объектами и свойствами приложения.
Существует целый ряд похожих на JSP инструментариев веб-разработки: для планировки и задания структуры (в них используются шаблоны), для привязки к данным с помощью языка выражений, а поведение UI задается с помощью обработчиков событий, реализованных средствами языка ECMAScript и интерфейса программирования Document Object Model. Форматирование данных выполняется с помощью специализированных библиотек тегов, для стилизации внешнего вида обычно применяется CSS (Cascading Style Sheets). Популярные представители этой категории инструментов: ASP, PHP, Struts, WebWork, Struts2, Spring MVC, Spyce и Ruby on Rails.
Значительная доля инструментариев для создания UI базируется на объектно-ориентированной модели. Обычно эти инструментарии предлагают библиотеку готовых элементов UI, и их главными преимуществами являются простота составления многократно используемых блоков из простых компонентов и интуитивно понятный, гибкий процесс программирования поведения и взаимодействия, основанный на обработчиках событий. В этих инструментариях все задачи разработки UI решаются с использованием специализированных объектных API. К данной категории относятся среды: Visual Basic, MFC, AWT, Swing, SWT, Delphi, Google Web Toolkit, Cocoa Touch UIKit, Vaadin и др. Сюда же можно отнести инструментарий Nokia Qt, предлагающий ряд оригинальных концепций. В некоторых инструментариях вся сложность взаимодействия между элементами структуры UI реализуется с помощью обработчиков событий, а в Qt в дополнение к ним есть «сигналы» и «слоты»: сигнал передается компонентом UI всякий раз, когда происходит определенное событие. Слот - это метод, вызываемый в ответ на определенный сигнал, который можно декларативно связать с каким угодно количеством слотов, и наоборот, один слот может получать сколько угодно сигналов. Элемент, передающий сигнал, «не знает», какой слот его получит. Таким образом, элементы пользовательского интерфейса слабо связаны соединениями «сигнал-слот». Данный механизм способствует использованию принципа инкапсуляции и предоставляет возможность декларативно задавать поведение UI.
Гибридные технологии относительно новы в мире разработки UI общего назначения - наряду с шаблонами и языками выражений в подобных инструментариях применяется объектный API. Типичный представитель - JavaServer Faces: библиотеки тегов служат для описания структуры и планировки, а также для форматирования данных; язык выражений - для привязки элементов и событий к серверным объектам и коду приложений; объектный API - для отображения элементов, управления их состоянием, обработки событий и контроля ввода. Другие популярные инструментарии в этой категории: ASP.NET MVC, Apache Wicket, Apache Tapestry, Apache Click и ZK Framework.
Среда Adobe Flex концептуально близка к технологиям этой категории, так как в ней для структурирования и планировки используются шаблоны, а программирование целиком выполняется на языке ActionScript. Подобно Qt, среда Flex предоставляет механизм для решения задач, связанных с программированием поведения и привязкой к данным.
Такие инструменты - новейшее направление в области средств разработки UI. Для указания структуры пользовательского интерфейса в них используются языки на основе XML и JSON (JavaScript Object Notation), а для остальных задач разработки UI применяется преимущественно декларативная нотация. В отличие от гибридных подходов, в основном рассчитанных на веб-интерфейсы, декларативные применяются еще в разработке нативных приложений для мобильных и настольных платформ.
API пользовательского интерфейса Android - событийно-зависимый, объектно-ориентированный, но наряду с основным в ОС есть вспомогательный API, базирующийся на XML, который позволяет декларировать структуру и планировку пользовательского интерфейса, а также стилизовать его элементы и управлять их свойствами. Декларативное описание интерфейса нагляднее показывает его структуру и помогает в отладке; позволяет без перекомпиляции менять планировку; помогает адаптироваться к различным платформам, размерам экрана и соотношениям его сторон. При создании более динамических пользовательских интерфейсов указывать и менять структуру элементов можно и программно - с помощью объектных API, но привязка к данным не поддерживается. Существует, правда, Android-Binding - стороннее решение с открытым кодом, позволяющее привязывать элементы пользовательского интерфейса к моделям данных.
Создавать UI для программ Windows и функционально богатых интернет-приложений, основанных, соответственно, на технологиях Windows Platform Foundation и Microsoft Silverlight, можно с использованием другого XML-словаря - eXtensible Application Markup Language (XAML). Он позволяет задавать структуру, планировку и стиль UI, а кроме того, в отличие от языка разметки Android, в нем поддерживается привязка к данным и возможность обработки событий.
В Nokia разработчикам рекомендуют Qt Quick - кросс-платформный инструментарий для настольных, мобильных и встраиваемых ОС, поддерживающий QML (декларативный скриптовый язык на основе синтаксиса JSON). Описание пользовательского интерфейса имеет иерархическую структуру, а поведение программируется на ECMAScript. Здесь, как и в обычном Qt, поддерживается механизм «сигнал-слот». Qt Quick поддерживает возможность привязки свойств элементов UI к модели данных, а также концепцию машины состояний, позволяющую графически моделировать поведение интерфейса.
Еще один пример - Enyo, кросс-платформный инструментарий для создания UI на ECMAScript, в котором структура интерфейса задается декларативно, а поведение регулируется обработчиками событий. События обрабатываются тремя способами: на уровне отдельных компонентов UI, путем передачи от потомка к родителю без прямой привязки, а также за счет шировоковещательной трансляции и подписки на такие сообщения (тоже без прямой привязки). Благодаря слабой связи элементов UI расширяются возможности многократного использования и инкапсуляции больших фрагментов интерфейса. По сути, основное достоинство Enyo - это модель инкапсуляции, благодаря которой UI можно компоновать из многократно используемых самодостаточных строительных блоков с заданными интерфейсами. Данная модель способствует абстрагированию и охватывает все архитектурные уровни UI. Участники проекта Enyo работают над реализацией поддержки привязки к данным.
Eclipse XML Window Toolkit - еще один инструментарий, ориентированный на декларативное описание UI. Первоначальная задача его создания состояла в объединении в Eclipse всех инструментов разработки UI, включая SWT, JFace, Eclipse Forms и другие - все их элементы так или иначе имеют соответствия в XWT. Структура и планировка UI в XWT задаются с помощью языка на основе XML, а для привязки к данным (доступа к Java-объектам приложения) используется язык выражений. Обработка событий программируется на Java, а для стилизации элементов интерфейса используется CSS. Механизм исполнения приложений XWT реализован в виде Java-апплета и элемента ActiveX, то есть может работать практически в любом браузере.
В этой категории существует немало похожих инструментов: в AmpleSDK, например, в качестве языка описания UI используется XUL, функции ECMAScript применяются для программирования динамического поведения, CSS - для стилизации. В Dojo Toolkit интерфейс задается декларативно и предусмотрены широкий выбор готовых элементов, объектное хранилище для доступа к данным и обработчик событий на основе ECMAScript с механизмом публикации-подписки. Инструментарий поддерживает интернационализацию, развитый API для опроса данных, модуляризацию и множественное наследование классов.
Значительная часть технологий разработки UI основана на моделях и предметно-ориентированных языках. В основном это модели интерфейсов, но могут использоваться и доменные модели. В обоих случаях модель нужна для генерации пользовательского интерфейса заранее либо интерпретируется в период исполнения. Этот класс технологий поднимает уровень абстракции, предлагает улучшенные систематические методы проектирования и реализации пользовательских интерфейсов, а также предоставляет инфраструктуру автоматизации соответствующих задач. Однако, по мнению некоторых исследователей , модельно-ориентированные технологии не дают универсального способа интеграции пользовательского интерфейса с приложением, а также пока нет согласия относительно того, какой набор моделей оптимально подходит для описания UI. Не решена задача привязки данных, и не объединены модели для решения других задач разработки UI.
Анализируя поколения модельно-ориентированных подходов к разработке UI начиная с 1990-х, можно прийти к выводу , что сегодня имеется общепринятое представление об уровнях абстракции и типах моделей, подходящих для разработки современных пользовательских интерфейсов, однако до сих пор нет единого мнения (стандартов) относительно информации (семантики), которую должны содержать различные модели. Считать базовыми можно модели задач, диалогов и презентации: презентационная модель решает задачи структурирования, планирования и стилизации; модель задач отвечает за привязку к данным - для каждой задачи указываются объекты UI и логики, с которыми предстоит работать; диалоговая модель охватывает поведенческие аспекты. Пример модели задач - Concurrent-TaskTrees (CTT), ее можно использовать совместно с языком MARIA, который реализует остальные модели UI . CTT в сочетании с MARIA представляет собой полноценный модельно-ориентированный инструментарий. Довольно большое семейство средств моделирования UI полагается также на язык UML, модели «сущность-связь» или подобные. Профили UML широко применяются в построении пользовательских интерфейсов бизнес-приложений. Существуют и другие активно используемые инструментарии - например, WebRatio, UMLi, Intellium Virtual Enterprise и SOLoist.
Небольшое, но значимое подмножество технологий формирования пользовательских интерфейсов генерируют UI, опираясь на модели пользователя, данных, задач или другие виды моделей приложения. Интерфейс генерируется исходя из модели целиком или полуавтоматически. Модели также могут интерпретироваться в период исполнения без использования в качестве основы для генерации интерфейса. В любом случае, благодаря высокому уровню автоматизации построения UI, технологии данной категории экономят время разработчика и снижают число ошибок, а генерируемые интерфейсы имеют единообразную структуру. Однако обобщенные UI не отличаются гибкостью, имеют ограниченную функциональность и непредсказуемый процесс генерации. Тем не менее при наличии прямой связи с доменной моделью разработка приложений с обобщенными UI вполне реальна. В данной категории около десятка примеров во главе с широко применяемым архитектурным шаблоном Naked Objects. Автоматическую генерацию UI можно с успехом применять в отдельных предметных областях - например, при дизайне диалоговых окон и пользовательских интерфейсов для удаленного управления системами. Дальнейшее развитие этого класса технологий исследователи видят в усовершенствовании методик моделирования и поиске новых способов комбинирования моделей в целях повышения удобства сгенерированных UI.
На рисунке представлена хронология появления различных инструментариев разработки UI, распределение их по категориям и основным областям применения, а в табл. 2 указаны способы, которыми каждая из технологий решает различные задачи разработки UI.
Для веб-разработки с целью развития общеупотребительных технологий характерны две противоположные тенденции. После технологий на основе шаблонов появились инструментарии с объектно-ориентированными API, которые чаще всего дополнялись шаблонами (в случае гибридных подходов) либо полностью заменяли их (GWT и Vaadin). В принципе, это вполне логично, учитывая общее превосходство объектно-ориентированных языков над шаблонными (наследование, полиморфизм, инкапсуляция, параметризация, многократное использование и т. д.), потребность в развитых концепциях и механизмах для составления обширных структур UI, а также «историю успеха» объектно-ориентированных API в эпоху настольных ПК.
Примечательно, что по сравнению с императивными и объектно-ориентированными способами формирования UI сегодня стали шире применяться декларативные - например, общеупотребительными становятся HTML, XML, XPath, CSS, JSON и подобные нотации. Большая часть структуры UI, как правило, статична, так что декларативные нотации отлично справляются с задачами структурирования, планировки и привязки к данным. Но поведенческие аспекты UI по-прежнему реализуются по классической событийно-зависимой парадигме, хотя есть исключения - когда применяются декларативные средства.
Заметная тенденция в развитии UI - ориентация на стандартные технологии и платформы. XML и ECMAScript сегодня популярны как никогда, хотя специализированные технологии, особенно из числа модельно-ориентированных, активно борются за жизненное пространство с большими техническими стандартами.
Можно назвать несколько задач, ждущих своего решения поставщиками инструментариев разработки и необходимых для задания многоуровневых архитектур. Пользовательские интерфейсы крупномасштабных бизнес-приложений нередко состоят из сотен страниц или больше, и в таких случаях абсолютно необходим четкий обзор системной архитектуры. Существует новая методика моделирования, которая решает эту проблему путем введения концепции капсулы, обеспечивающей строгую инкапсуляцию фрагментов UI и позволяющей задавать архитектуру с разными уровнями детализации. Капсула уже обладает внутренней структурой, которую можно последовательно рекурсивно применять на всех более низких уровнях компонентов UI. Аналогичную задачу пытаются решить разработчики Enyo и WebML.
Гибкость, расширяемость и широта поддержки инструментальных средств - реальные преимущества общеупотребительных технологий разработки UI, однако пока они страдают от довольно низкого уровня абстракции и недостаточной выразительности. С другой стороны, модельно-ориентированным подходам стоит избегать наследования семантики от низкоуровневых моделей UI, в противном случае абстрактные модели пользовательских интерфейсов могут стать такими же сложными, как и сама реализация UI. Вместо использования знаний из предметной области UI и семантики модели приложения, от дизайнеров пользовательских интерфейсов по-прежнему требуется непосредственная работа с низкоуровневыми компонентами: диалоговыми окнами, меню и обработчиками событий.
Технологиям разработки UI свойственна еще одна серьезная проблема, связанная с требованиями адаптации для многих целевых платформ, характерными для всех современных интерактивных приложений. К счастью, модельно-ориентированное сообщество вовремя отреагировало - в 2003 году была предложена объединяющая универсальная архитектура для процессов, моделей и методов, используемых при построении многоплатформных UI.
Нынешнее многообразие компьютерных устройств и платформ несколько напоминает эпоху настольных ПК конца 90-х с ее обилием предлагаемых разными поставщиками инструментариев для построения пользовательских интерфейсов. На сегодня HTML5 еще не решил проблему технологической разноголосицы ввиду ограниченной поддержки аппаратных функций и интерфейсов программирования. В конечном счете, как и в случае со многими проблемами программной инженерии, сегодня для разработки UI нужны понятные и простые решения, требующие, однако, от их создателей невероятно много усилий по реализации.
Жарко Мияйлович ([email protected]) - старший инженер, Драган Миличев ([email protected]) - доцент, Белградский университет.
Zarko Mijailovic, Dragan Milicev, A Retrospective on User Interface Development Technology, IEEE Software, November/December 2013, IEEE Computer Society. All rights reserved. Reprinted with permission.
Командный интерфейс
Наиболее старым интерфейсом является командный интерфейс (интерфейс командной строки ), который был наиболее распространен в период расцвета больших многопользовательских систем с алфавитно-цифровыми дисплеями. Для командного интерфейса характерно взаимодействие пользователя с ЭВМ с помощью командной строки, в которую вводятся команды определенного формата, а затем передаются к исполнению.
Командный интерфейс реализован в виде пакетной технологии и технологии командной строки.
Для ввода информации пользователь использует клавиатуру или другое символьное устройство ввода. Пользователь получает информацию в виде текста посредством дисплея или печатающего устройства (довольно редко).
Рисунок 1. Пример командного интерфейса
Работа с командным интерфейсом заключалась в следующем:
Замечание 1
Интересной особенностью интерфейса командной строки является возможность взаимодействия двух программ посредством имитации управляющей программой действий пользователя. Простота подачи команд и анализа выводимого текста делает это весьма эффективным.
К преимуществам интерфейса командной строки относят:
Недостатками командного интерфейса считают:
Наиболее часто командный интерфейс используется при работе с командным интерпретатором, который используется как интерфейс управления операционной системой (Linux, xBSD, QNX, MS-DOS и др.).
Графический интерфейс , WIMP-интерфейс (Window Image Menu Pointer) является неотъемлемым компонентом большинства современного программного обеспечения, которые ориентированы на работу конечного пользователя. Диалог пользователя с ПК в графическом интерфейсе ведется при помощи графических объектов: меню, значков и других элементов.
Основные достоинства графического интерфейса:
При работе с графическим интерфейсом для манипуляций с графическими объектами используются мышь и клавиатура. Пользователь работает с экранными формами, которые содержат объекты управления, меню, панели инструментов.
Рисунок 2. Пример графического интерфейса
Речевой интерфейс , SILK-интерфейс (Speech Image Language Knowledge) на данный момент существует только как «голосовой» (не считая биометрические интерфейсы, которые применяются не для управления ПК, а только для идентификации пользователя). Использование речевого интерфейса является очень перспективным направлением, т.к. введение информации с помощью голоса – самый быстрый и удобный способ. Т.к. качество распознавания устной речи пока не идеально, практическая реализация речевого интерфейса еще не стали доминирующими.
Речевой интерфейс обеспечивает приближенную к обычной, человеческой форму общения. ПК анализирует человеческую речь, находит в ней ключевые слова, по которым определяет команды. Речевой интерфейс требует высоких показателей аппаратных ресурсов ПК, поэтому его использование пока ограничено военным делом.
Рисунок 3.
При использовании речевого интерфейса на экране по команде пользователя ПК осуществляет переход между поисковыми образами, используя смысловые семантические связи. Речевая система дает возможность повысить эффективность работы вследствие того, что:
Замечание 2
Современные операционные системы поддерживают командный, графический и речевой интерфейсы.
В последнее время внимание привлекают новые виды интерфейса, такие как биометрический (мимический) и семантический (общественный). В связи с этим поставлена проблема создания общественного интерфейса, который будет включать в себя лучшие решения графического и речевого интерфейсов.
В прошедний понедельник мне посчастливилось попасть на собеседование на Senior .Net Developer в одну международную компанию. Во время собеседования мне предложили пройти тест, где ряд вопросов был связан с.Net. В частности в одном из вопросов надо было дать оценку (истина/ложь) ряду утверждений, среди которых было и такое:
В.Net любой массив элементов, например int, по умолчанию реализует IList, что позволяет использовать его в качестве коллекции в операторе foreach.
Быстро ответив на этот вопрос отрицательно и отдельно дописав на полях. что для foreach необходима реализация не IList, а IEnumerable, я перешел к следующему вопросу. Однако по дороге домой меня мучал вопрос: реализует ли массив все-таки этот интерфейс или нет?
Про IList я смутно помнил, что этот интерфейс дает мне IEnumerable, индексатор и свойство Count, содержащее число элементов коллекции, а также еще пару редко используемых свойств, типа IsFixedCollection(). Массив имеет свойство Length для своего размера, а Count в IEnumerable является методом расширения от LINQ, что было бы невозможно, если бы этот метод был реализован в классе. Таким образом, получалось, что массив не мог реализовывать интерфейс IList, однако какое-то смутное чувство не давало мне покоя. Поэтому вечером после интервью я решил провести небольшое исследование.
Var v = new int { 1, 2, 3 }; var t = v.GetType(); var i = t.GetInterfaces(); foreach(var tp in i) Console.WriteLine(tp.Name);
Вот полный список полученных интерфейсов из окна консоли:
ICloneable IList ICollection IEnumerable IStructuralComparable IStructuralEquatable IList`1 ICollection`1 IEnumerable`1 IReadOnlyList`1 IReadOnlyCollection`1
Таким образом, массив в.Net все-таки реализует интерфейс IList и его обобщённый вариант IList<> .
Чтобы получить более полную информацию я построил диаграмму класса System.Array.
Мне сразу бросилась в глаза моя ошибка: Count было свойством не IList, а ICollection, еще предыдущего интерфейса в цепочке наследования. Тем не менее, сам массив уже не имел такого свойства, как и многих других свойств интерфейса IList, хотя другие свойства этого интерфейса, IsFixedSize и IsReadOnly были реализованы. Как такое вообще возможно?
Всё сразу встает на свои места, когда вспоминаешь о том, что в С# можно реализовывать интерфейсы не только
неявно (implicit), но и явно (explicit). Я знал об этой возможности из учебников, где приводился пример такой имплементации в случае. когда базовый класс уже содержит метод с тем же именем, что и метод интерфейса. Я также видел такую возможность в ReSharper. Однако до настоящего времени мне напрямую не приходилось сталкиваться с необходимостью явной реализации интерфейсов в моих собственных проектах.
| Критерии |
Неявная (implicit) реализация |
Явная (explicit) реализация |
|---|---|---|
| Базовый синтаксис |
interface ITest
{
void DoTest();
}
public class ImplicitTest: ITest
{
public void DoTest()
{ }
}
|
interface ITest { void DoTest(); } public class ExplicitTest: ITest { void ITest.DoTest() { } } |
| Видимость |
Неявная имплементация всегда являелся открытой (public), поэтому к методам и свойствам можно обращаться напрямую. var imp = new ImplicitTest(); imp.DoTest(); |
Явная имплементация всегда закрыта (private). Чтобы получить доступ к имплементации необходимо кастовать инстанцию класса к интерфейсу (upcast to interface). var exp = new ExplicitTest(); ((ITest)exp).DoTest(); |
| Полиморфия |
Неявная имплементация интерфейса может быть виртуальной (virtual), что позволяет переписывать эту имплементацию в классах-потомках. |
Явная имплементация всегда статична. Она не может быть переписана (override) или перекрыта (new) в классах-потомках. Прим. 1 |
| Абстрактный класс и реализация |
Неявная реализация может быть абстрактной и реализовываться только в классе-потомке. |
Явная реализация не может быть абстрактной, но сам класс может иметь другие абстрактные методы и сам быть абстрактным. Прим. 2 |
Прим. 2 - В одном из блогов указано, что класс сам не может быть абстрактным. Возможно это было верно для какой-то из предыдущих версий компилятора, в моих экспериментах я без проблем мог реализовать интерфейс явно в абстрактном классе.
/* Listing 1 */ interface IJogger { void Run(); } interface ISkier { void Run(); } public class Athlete: ISkier, IJogger { public void Run() { Console.WriteLine("Am I an Athlete, Skier or Jogger?"); } }
Кстати, этот пример является корректным кодом в C#, то есть он (корректно) компилируется и запускается, при этом метод Run() является одновременно и методом самого класса, и реализацией аж двух интерфейсов. Таким образом, мы можем иметь одну реализацию для разных интерфейсов и для самого класса. Проверить это можно следующим кодом:
/* Listing 2 */ var sp = new Athlete(); sp.Run(); (sp as ISkier).Run(); (sp as IJogger).Run();
Результатом исполнения этого кода будет «Am I an Athlete, Skier or Jogger?» , выведенное в консоли три раза.
Именно здесь мы можем использовать явную реализацию интерфейса для того, чтобы разделить все три случая:
/* Listing 3 */ public class Sportsman { public virtual void Run() { Console.WriteLine("I am a Sportsman"); } } public class Athlete: Sportsman, ISkier, IJogger { public override void Run() { Console.WriteLine("I am an Athlete"); } void ISkier.Run() { Console.WriteLine("I am a Skier"); } void IJogger.Run() { Console.WriteLine("I am a Jogger"); } }
В данном случае при исполнении кода из Listing 2 мы увидим в консоли три строчки, «I am an Athlete» , «I am a Skier» и «I am a Jogger» .
/* Listing 4 */ public class Code { public void Run() { Console.WriteLine("I am a class method"); } } interface ICommand { void Run(); void Execute(); } public class CodeCommand: Code, ICommand { // implicit interface method implementation // => public implementation // implicit base class method hiding (warning here) public void Run() { base.Run(); } // explicit interface method implementation // => private implementation void ICommand.Execute() {} }
Это позволяет использовать реализации отдельных методов интерфейса как родных методов класса и они доступны, например, через IntelliSense, в отличие от явной реализации методов, которые являются приватными и видны только после каста к соответствующему интерфейсу.
С другой стороны, возможность приватной реализации методов позволяет скрывать ряд методов интерфейса, при этом полностью его имплементируя. Возвращаясь к нашему самому первому примеру с массивами в.Net, можно увидеть, что массив скрывает, например, имплементацию свойства Count интерфейса ICollection, выставляя наружу это свойство под именем Length (вероятно это является попыткой поддержания совместимости с С++ STL и Java). Таким образом, мы можем скрывать отдельные методы реализованного интерфейса и не скрывать (=делать публичными) другие.
Здесь, правда, возникает такая проблема, что во многих случаях совершенно невозможно догадаться о том, какие интерфейсы реализованы классом «неявно», поскольку ни методы, ни свойства этих интерфейсов не видны в IntelliSense (здесь также показателен пример с System.Array). Единственным способом выявления таких реализаций является использование рефлексии, например при помощи Object Browser в Visual Studio.
/* Listing 5 */ interface IFingers { void Thumb(); void IndexFinger(); // an obsolete interface method // void MiddleFinger(); } public class HumanPalm: IFingers { public void Thumb() {} public void IndexFinger() {} // here is a "dangling" public method public void MiddleFinger() {} } public class AntropoidHand: IFingers { void IFingers.Thumb() {} void IFingers.IndexFinger() {} // here the compiler error void IFingers.MiddleFinger() {} }
В случае приватной реализации интерфейсов все классы с явной реализацией несуществующего более метода просто перестанут компилироваться, однако после удаления ставшей ненужной реализации (или ее рефакторинга в новый метод) у нас не будет «лишнего» публичного метода, не привязанного к какому-либо интерфейсу. Конечно, возможно потребуется рефакторинг зависимостей от самого интерфейса, но здесь, по крайней мере, не будет нарушения принципа «program to interfaces, not implementations».
Что касается свойств, то неявно реализованные свойства интерфейса (properties) позволяют обращаться к ним через методы-акцесоры (getter и setter) как извне, так и непосредственно из самого класса, что может привести к ненужным эффектам (например, к ненужной валидации данных при инициализации свойств).
/* Listing 6 */ interface IProperty { int Amount { get; set; } } public class ClassWithProperty: IProperty { // implicit implementation, public public int Amount { get; set; } public ClassWithProperty() { // internal invocation of the public setter Amount = 1000; } } public class ClassWithExplicitProperty: IProperty { // explicit implementation, private int IProperty.Amount { get; set; } public ClassWithExplicitProperty() { // internal invocation isn"t possible // compiler error here Amount = 1000; } }
При явной имплементации свойств интерфейса эти свойства остаются приватными и для доступа приходится идти «длинным» путём и объявлять дополнительную закрытое поле, через которое и происходит инициализация. В результате это приводит к более чистому коду, когда методы доступа к свойству используются только для доступа извне.
Таким образом, мы с одной стороны как бы делаем код несколько менее гибким (например ReSharper по умолчанию всегда предлагает использовать декларацию с var если это возможно), но зато избегаем потенциальных проблем, связанных с привязкой к конкретной имплементации, по мере роста системы и объема её кода. Этот пункт может показаться многим спорным, но в случае, когда над проектом работает несколько человек, да еще в разных концах света, использования явной типизации может быть очень даже полезным, так как это повышает читабельность кода и уменьшает затраты на его поддержку.
«Передаточный механизм» - Итог урока. Технология 3 класс. Обучение конструированию различных технических моделей с приводом механизма. Перекрёстная передача - когда колёса крутятся в разных направлениях. Виды передач: 1 - ременная; 2 - цепная; 3 - зубчатая. Изделия, имеющие передачу: транспортёр, подъёмный кран, мельница. Главная часть конструкции мельницы - передаточный механизм.
«Интерфейсы компьютера» - Пользовательский интерфейс. Программное обеспечение. Служебные программы. Персональный компьютер как система. Обеспечивается операционной системой компьютера. Укажите входы и выходы. Аппаратный интерфейс. Аппаратно-программный интерфейс. Операционная система. Текстовые файлы. Системные программы. Аппаратно-программный интерфейс – взаимодействие аппаратного и программного обеспечения компьютера.
«Технологии на уроках» - Формы организации могут быть разные: урок, групповая, индивидуальная, парная. Активный и интерактивный методы применяются мной с 5 по 11 классы. Виды технологий: Технология личностно-ориентированного обучение. Технология развивающего обучения. Технология личностно-ориентированного обучение Проектно-исследовательская технология.
«Образовательные технологии в школе» - Лаборатория нерешенных проблем. Методическая поддержка творческих проектов ОУ и преподавателей. Игровые технологии. Рост показателя использования ИКТ в учебном процессе. Распространение передового педагогического опыта. Снижение количества второгодников. Рост мастерства педагогов, влияние на качество урока.
«Технология 6 - 7 - 8 класс» - В чём измеряется электрическая энергия? Какая мерка определяет размер плечевого изделия? Что, по народным представлениям, означало начало всего живого? Какая деталь приводит в движение все рабочие органы швейной машины? Исходное сырье для изготовления кареты для Золушки. Какую функцию выполняют желобки на лезвии иглы?
«Разделы технологии» - А у нас из блестящего бисера - Необычная красота. Предмет – Технология. Лоскутное шитье издавна известно многим народам. Национальные праздники и обряды, национальная одежда. Рассказывают о традициях разных народов, национальных праздниках и обрядах. После выпечки пампушки немного охладить, натереть толченым чесноком.
