Описания интерфейса программы ensp и интерфейсы являются наиболее важной концепцией в разработке программного обеспечения

Отвечаем на самые популярные вопросы

Время на прочтение

Для нас не секрет, что многие специалисты, работающие с сетевым оборудованием Huawei имеют к нам ряд вопросов.

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

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

Прежде чем начать, хотим предупредить, что для доступа к части полезного контента, о котором пойдет речь, вам будет необходимо пройти несложную регистрацию на портале Huawei.

Теперь, когда все прелюдии закончены, переходим к главному.

Читайте документацию!

Да-да, именно так! Ответы на большую часть задаваемых вопросов можно без особых трудозатрат почерпнуть из доступных на портале компании документов.

Вы можете возразить, мол «бытует мнение, что какой-либо стоящей документации на оборудование Huawei в публичном доступе не существует — и вообще, есть сомнения, что таковая существует в природе».

Отвечаем — это миф. Безусловно, он возник не на пустом месте, и несколько лет назад, когда было создано подразделение Huawei Enterprise, большая часть материалов и документации действительно носила гриф «Internal», а портал компании был не богат общедоступными материалами. Однако времена меняются, процессы компании меняются вместе с ними, и в настоящий момент портал поддержки предлагает пользователям огромное количество различной документации на оборудование Huawei.

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

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

Для примера, взгляните на документ на серию маршрутизаторов AR G3 версии V200R008 — «Huawei AR120&AR150&AR160&AR200&AR500&AR510&AR1200&AR2200&AR3200&AR3600 Product Documentation».

Найти такие документы труда не составит — выберите в разделе поддержки интересующий продукт и примените фильтр по категории «Product Documentation»:

Лайфхак номер два

Итак, вы нашли нужный вам документ, но это ещё не все приятности!

Обратите внимание — при открытии соответствующей библиотеки в режиме онлайн-просмотра вверху страницы отображаются ссылки для скачивания данной библиотеки, а также программы «HedexLite» для её просмотра:

В этой документации собрано огромное количество удобно скомпонованной по разделам информации, которая снабжена перекрёстными ссылками для простоты использования:

• Список новых функций в текущей версии с описанием возможностей.
• Описание линейки, позиционирование моделей, типовые сценарии использования и прочее.
• Описание аппаратной платформы, включающее:

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

• Инструкция по монтажу.
• Подробная инструкция по настройке, разбитая на секции (в рамках каждой секции — набор типовых разделов конфигурации с описанием шагов и ссылками на встроенный же «command reference», где описаны все возможные параметры команд).

• Раздел «Operation and Maintenance» с описанием эксплуатационных регламентов (если требуются) и типовыми опросниками с командами для проверки состояния устройств.
• Раздел с описанием возможных аварий и порядком действий, которые необходимо выполнить при возникновении инцидентов, а также сборник инструкций по диагностике и решению типовых неисправностей (например, инструкция по сбросу пароля на консоль, если он по какой-либо причине был утерян).
• Уже упомянутый «command reference» с подробным описанием всех возможных параметров команд конфигурации и диагностики.

Скачав HedexLite, вы получаете ряд дополнительных полезных функций, таких как:

• загрузка документации с портала поддержки;
• проверка наличия обновления документов в библиотеке, а также проверку наличия уже неактуальных версий документов (которые можно удалить);
• гибкая система поиска по документации, с возможностью фильтрации результатов поиска по разделам; например, выполнив поиск по ключевому сообщению «ospf», можно отфильтровать результаты по типу документа:

Эмулятор сетевого оборудования eNSP!

Этот лайфхак для тех, кто хочет познакомиться с командной строкой оборудования Huawei, подготовиться к сертификационным экзаменам или собрать какую-то виртуальную сетевую топологию для других задач.

Для создания виртуальных топологий доступны маршрутизаторы серии ARG3, коммутаторы серий Sx700 и CloudEngine, Wi-Fi контроллер и точки доступа, МСЭ USG и ряд вспомогательных инструментов (ПК, сервер, мобильный клиент). Модульные маршрутизаторы (AR1200-3200) можно комплектовать типовыми платами — их количество в эмуляторе значительно меньше, чем доступно к заказу, но эмулировать наиболее распространённые линии связи FE/GE/G.SHDSL/Serial вполне возможно.

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

Для эмуляции оборудования используются встроенные образы VRP. А для топологий с большим числом устройств (и следовательно высокими требованиями к количеству оперативной памяти и ресурсов процессора) предусмотрена работа в режиме «клиент-сервер», когда запуск виртуальных устройств происходит на удаленном сервере, снимая тяжелые вычислительные задачи с вашего ПК.

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

Необходимо заметить — для работы с эмулятором требуется Oracle VM VirtualBox (включен в состав установочного пакета).

В дальнейшем проверка на наличие обновленных версий программы эмулятора производится автоматически.

«Стенсилы» для Visio!

Следующий лайфхак — большой подарок от Huawei! Ведь он будет полезен не только специалистам, работающим с оборудованием Huawei, но и всем тем, кому приходилось (и приходится) заниматься подготовкой проектной документации или, в крайнем случае, созданием верхнеуровневой схемы сети.

Независимо от того, оборудование каких производителей используется в ваших проектах — наши «стенсилы» для MS Visio порадуют всех авторов проектной документации и сетевых схем.

Всё на том же портале поддержки (где концентрация полезности на квадратный сантиметр просто зашкаливает:) вас ожидают два варианта «стенсилов»:

• Иконки сетевых устройств и вспомогательных элементов (в двух цветах) для создания топологий сети и схем на любой случай жизни:
• Фасады устройств с «магнитящимися» блоками и платами для отрисовки наполнения стоек

Из них можно собрать необходимый в проекте фасад стойки с оборудованием:

Лайфхак номер пять

Тенденция миграции традиционного ПО и утилит со стационарных ПК на интернет-порталы уже давно ни для кого не секрет: Google Docs/Sheets, графические редакторы и прочее.

И мы верим в перспективы развития «онлайн-инструментов», в удобство их использования, и поэтому стремимся развивать и наполнять портал поддержки Huawei.

Помимо тех инструментов, о которых мы рассказали выше, на нашем портале поддержки можно найти целый ряд других полезных «онлайн-инструментов». И там вы сможете найти ответы на большое количество своих вопросов.

И самое главное: не стесняйтесь задавать свои вопросы нам — именно ваши потребности помогают нам в реализации новых идей того, как нам облегчить и сделать удобнее вашу работу с сетевым оборудованием Huawei.

Не оставайтесь «один на один» со своими проблемами 🙂

Построение топологии
Выберите значок End Device на верхней левой панели, чтобы показать список конечных
устройств, которые могут быть применены. Выберите значок Laptop, перетащите его на
панель холста, отпустите значок, чтобы разместить его на холсте.

Создание физической среды
Выберите значок соединений на верхней левой панели, чтобы показать список сред,
которые могут быть применены в топологии. Выберите медную (Ethernet) среду из списка.
После нажатия на значок курсор будет представлять соединитель для отображения
текущей роли курсора в качестве соединителя. Нажмите на клиентское устройство,
чтобы открыть список интерфейсов порта, поддерживаемых имитируемым устройством.
Для клиента выберите опцию Gigabit Ethernet 0/0/1, чтобы применить соединение

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

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

Наблюдение за захваченным потоком трафика
Экземпляр инструмента захвата пакетов Wireshark должен быть активен после
выполнения захвата данных на клиентском интерфейсе. Развернуть активное окно для
наблюдения за результатами процесса захвата пакетов.

Топология
Рис. 2.1 Лабораторная топология для базовой навигации и работы VRP
Сценарий
Компания приобрела два маршрутизатора AR G3, которые необходимо ввести в
эксплуатацию, прежде чем их можно будет использовать в корпоративной сети. Пункты
ввода в эксплуатацию включают в себя настройку имен устройств, системного времени и
управления паролями.

Ubuntu потрясающая операционная система, давно не работал с Ubuntu server, а обновлять свой Desktop со стабильной версии не было смысла. И вот не давно пришлось столкнутся со свеженьким релизом Ubuntu server 18.04, моему удивлению не было предела. Когда я понял что я бесконечно отстал от жизни и не могу настроить сеть, т.к старая добрая система настройки сетевых интерфейсов по средствам редактирования файла /etc/network/interfaces канула в Лету. А что же пришло ей на смену? Что-то ужасное и на первый взгляд совершенно не понятное, встречайте «Netplan».

Признаться честно, сначала я не мог понять в чем дело и ”зачем это нужно, ведь все было так удобно”, но получив немного практики понял, что в нем есть свой шарм. И так хватит лирики продолжим. Что же такое Netplan — это новая утилита для настройки сети в Ubuntu, по крайне мере «в других дистрибутивах я не встречал подобного». Существенное отличие Netplan является то, что конфигурация пишется на языке YAML, да да вы не ослышались YAML, разработчики решили идти в ногу со временем (и как бы много не расхваливали его я все-таки считаю его ужасным языком). Основной минус этого языка в том что он очень чувствителен к пробелам, давайте же рассмотрим конфиг на примере.

Файлы конфигурации находятся по пути /etc/netplan/имяфайла.yaml, между каждым блоком когда должно быть + 2 пробела.

1) Стандартная шапка выглядит так:

network:
version: 2
renderer: networkd
ethernets:
enp3s0f0:
dhcp4:no

Давайте рассмотрим что мы сейчас сделали:

• network: — это блок начало конфигурации.
• renderer: networkd — здесь мы указываем сетевой менеджер который будем использовать, это либо networkd либо NetworkManager
• version: 2 — тут, как я понял, версия YAML.
• ethernets: — этот блок говорит о том, что будем конфигурировать ethernet протокол.
• enps0f0: — указываем какой сетевой адаптер будем конфигурировать.
• dhcp4:no — отключаем DHCP IPv4, для IPv6, dhcp6 соответственно

2) Попробуем назначить ip адреса:

Здесь мы задали мак, ipv4, шлюз и dns сервер. Заметьте, что если нам нужно больше одного ip адреса, то мы пишем их через запятую с обязательным пробелом после.

3)А что если нам нужен bonding?

• bonds: — блок, поясняющий что мы будем настраивать bonding.
• bond0: — произвольное имя интерфейса.
• interfaces: — набор интерфейсов собираемых в bond-динг, ”как оговаривалось ранее если параметров несколько описываем их в квадратных скобках”.
• parameters: — описываем блок настройки параметров
• mode: — указываем мод по которому будет работать bonding.
• mii-monitor-interval: — задаем интервал мониторинга 1 сек.

Внутри блока с именем bond-а также можно конфигурировать такие параметры как addresses,gateway4,routes итд.

Мы добавили резервирование для нашей сети, теперь осталось только повесить vlan и настройку можно считать оконченной.

• vlans: — объявляем блок настройки vlan.
• vlan10: — произвольное имя vlan интерфейса.
• id: — тег нашего vlan.
• link: — интерфейс через который vlan будет доступен.
• routes: — объявляем блок описания маршрутов.
• — to: — задаем адрес/подсеть до которой необходим маршрут.
• via: — указываем шлюз через которой будет доступна наша подсеть.
• on-link: — указываем что прописывать маршруты всегда при поднятии линка.

Обратите внимание на то, как я расставляю пробелы, в языке YAML это очень важно.

Вот мы описали сетевые интерфейсы, создали bonding, и даже добавили vlan-ы. Давайте применим наш конфиг, команда netplan apply проверит наш конфиг на наличие ошибок и применит его в случае успеха. Далее конфиг будет сам подниматься при перезагрузке системы.

Собрав все предыдущие блоки кода, вот что у нас получилось:

Вот наша сеть и готова к эксплуатации. Все оказалось не так страшно, как показалось вначале и код получился очень красивый и читабельный.
P.S спасибо что по netplan есть отличный мануал по ссылке https://netplan.io/.

Всем доброго дня.

Начал экспериментировать с eNSP.
Взял первый в списке AR201 маршрутизатор.

Странности:
1. у него 8 интерфейсов, но виден в выводе только 1:

2. Ему, 8му, можно присвоить ip и это работает:

Но остальным интерфейсам адреса присвоить нельзя. почему?

Так что же там с интерфейсами творится?

Интерфейс можно считать своеобразным договором между системой и внешним окружением. В рамках компьютерной программы «система» — рассматриваемая функция или модуль, а «окружение» — весь остальной проект. Интерфейс формально описывает, какие данные могут передаваться между системой и окружением. А «реализацию» можно охарактеризовать как «система минус интерфейс». В языках наподобие Haskell интерфейсы могут быть крайне специфическими. А в языках вроде Python они, напротив, очень обыденны. Выбранный тип интерфейса может повлиять на размер созданного технического долга и производительность программиста. О том, как это посчитать, написано ниже. Также будет предложен метод для оценки и сравнения разных интерфейсов. На основании этих сравнений вы сможете сами понаблюдать за способами использования языка или программного инструмента.

Важнейшая концепция в разработке ПО — концепция интерфейса. Эта статья не об интерфейсах на Java, а об интерфейсах в программном дизайне. И в меньшей степени — об интерфейсах в окружающем мире. Конечно, в разработке ПО используется немало других важных концепций, но я считаю, что большинство из них так или иначе зависят от важности интерфейса.

Что такое интерфейс?

Большинству из нас знакомы две краткие формулировки:

Интерфейс — это договор между системой и внешним окружением.
Интерфейс — это сопряжение системы с внешним окружением.

Интерфейс = Система ∩ Окружение

Определение с сопряжением подходит лучше, если система — это физический объект. Оба определения очень абстрактны, поэтому давайте рассмотрим их на примере печатания на клавиатуре:

Здесь система — ноутбук, окружение — руки (а также лапы кота, забравшегося на клавиатуру). Следовательно, интерфейс должен быть любой частью взаимодействия между руками и ноутбуком, которую нельзя отнести лишь к какой-то одной из сторон, а только к обеим. Обычно мы думаем о руках и о клавиатуре обособленно, так что точные границы интерфейса в данном случае — предмет философского спора. Вам решать: будет ли это клавиатура в целом или отдельные атомы, взаимодействующие друг с другом при контакте пальцев и клавиш.

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

Всё это любопытные философские рассуждения, но как они относятся к написанию ПО? Ну, начнём с того, что интерфейсы в программировании окружают вас со всех сторон, даже если вы не обращаете на это внимания. Например, если вы программируете на Java, то явным образом именуете интерфейсы в зависимости от их назначения. И в других языках они тоже присутствуют. Давайте рассмотрим пример интерфейса функции add_numbers:

Применим ту же методику цветовой дифференциации

для описания окружения, системы add_numbers и интерфейса:

Рассматриваемая здесь «система» состоит из функции add_numbers. Если вы скажете, что можно рассматривать как отдельную систему основной метод — other_function, — то будете правы. Но для простоты мы считаем функцию add_numbers изолированной системой. Также целесообразно считать частью интерфейса обращения к add_numbers.

Как видите, здесь добавлена четвёртая концепция: «реализация». Довольно сложно дискутировать на тему интерфейсов без учёта конкретных реализаций. Давайте определим этот термин:

Реализация — это система минус интерфейс.

Implementation = System ∖ Interface
Implementation = System ∖ (System ∩ Environment)

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

Интерфейс как договор

Если рассматривать интерфейс функции add_numbers в виде договора, то гарантии будут такие:

• Функция add_numbers существует.
• add_numbers имеет только два параметра, каждый из которых является unsigned int.
• add_numbers возвращает лишь один unsigned int.

Интерфейс этой функции ничего не говорит нам:

• о прерывании выполнения add_numbers;
• об асимптотической сложности рантайма add_numbers;
• о количестве свободной памяти, необходимой для запуска add_numbers;
• о конкретной реализации unsigned int;
• о побочных эффектах (выделение памяти, модифицирование глобальных переменных).

Описанный выше интерфейс add_numbers известен под видом функции prototype. В предыдущих версиях K&R C использовалась более слабая форма описания интерфейсов:

unsigned int add_numbers();

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

С компьютерными программами всё то же самое. Модули и функции говорят, что им нужно и (иногда) что они дадут взамен. Нарушение этого договора приведёт к ошибке компиляции, к ошибке выполнения, к сбою приложения, системы, средств контроля качества кода и к выговору от руководства. Я бы даже сказал, что определение интерфейса как договора не метафорическое. Здесь используются те же принципы, что и в коммерческом договоре, хотя он и не столь детализирован.

Патенты, авторские права и интерфейсы

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

Итак, я склонен буквально рассматривать интерфейс как «коммерческий договор» между двумя сущностями. Подчёркиваю — я не считаю это метафорой. Особенно я адресую эту интерпретацию специалистам по теории вычислительных машин и защитникам авторских прав.

Следует ли патентовать интерфейс? Учитывая его определение как договора между системой и окружением, я считаю, что использование патентов было бы ошибкой. И, судя по всему, существующее прецедентное право поддерживает мою позицию. Но имейте в виду, что слово «интерфейс» используется очень широко, и зачастую совсем не в том смысле, как я описал выше.

Следует ли защищать интерфейс авторскими правами? Опять же, учитывая «договорную» природу, я считаю, что объектом авторского права должен быть «исходный код» интерфейса. В то же время авторские права не должны применяться к тем аспектам интерфейсов, которые делают их такими особенными. Достаточно лишь защитить исходный код или рукописное изображение, но не гарантии или ограничения. Если гарантии или ограничения интерфейса станут неотделимы от любой из частей его кода, то эти части следует лишить права защиты.

Предлагаю простой тест, позволяющий оценить, нужно ли что-то защищать авторскими правами.

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

Считаю, что с помощью этого теста целесообразно проверять ещё и на патентоспособность. Обратите внимание: цель теста — исключительно определить нецелесообразность защиты авторскими правами или патентом. Он не поможет в решении о том, что следует подвергнуть защите. Кроме того, этот тест — лишь моё мнение, а не нормативный акт или закон.

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

def foo():
print(“asdf”)

def foo(abc):
print(abc)

foo(“lol”)

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

Думаю, многие переживали, что будет создан прецедент, позволяющий защищать патентом или авторскими правами элементы интерфейса. Как раз тот случай, при котором не был бы пройден мой тест. Окружной суд принял решение: «Структура, последовательность и архитектура API могут быть защищены авторским правом». Не думаю, что это проблема, поскольку «структура, последовательность и архитектура» по своему определению вполне пройдут мой тест. Приведу пару выдержек из статьи по приведённой выше ссылке:

«Окружной суд заключил, что „есть лишь один способ написания“ объявлений для взаимодействия с Java. Если это так, то использование одинаковых объявлений не подлежит защите авторским правом. В Google не оспаривают тот факт, что они могли бы написать свои собственные API для доступа к Java, за исключением трёх». И наконец, «В Google признали, что они дословно скопировали объявления».

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

Об этой тяжбе я знаю лишь из открытых сетевых источников, но, судя по всему, в Google полностью скопировали исходный Java-код, включая интерфейсы. Похоже, они и сами считали, что нужно лицензировать своё использование Java, поскольку это было предметом переговоров по лицензионным соглашениям с Sun ещё до 2010 года. Но эти соглашения потерпели неудачу после того, как Sun была приобретена Oracle. Тем не менее Google продолжала использовать «дословные» копии кода, что явно не пошло ей на пользу при судебном разбирательстве. Подозреваю, что их адвокаты знали о слабости своей позиции, поэтому выбрали стратегию защиты, основанную на законном требовании о нераспространении авторского права на интерфейсы. Надеялись выиграть дело за счёт представления интерфейса в виде исходного кода и его объединения с более философской концепцией.

Что такое «модуль», или «абстракция»?

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

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

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

Вы можете считать отдельную функцию модулем в языке С, «модулем» — в Python, классом или пакетом — в Java. Чем угодно, лишь бы оно имело внешний интерфейс и «скрытую» реализацию. Причём «скрытость» может быть следствием правил языка или даже решения программиста.

Дырявые абстракции

Насколько я знаю, идею дырявых абстракций выдвинул Джоел Сполски. В его эссе есть несколько хороших примеров, но я хотел бы привести свой. В программировании очень часто встречается концепция «карты»: представление структуры данных, состоящей из пар ключей и значений. Важное ограничение: карта гарантирует, что все ключи должны быть уникальными. Попытка записи нового значения для существующего ключа приведёт к ошибке или перезаписи предыдущего значения. Суть в том, что ключи не должны дублироваться. Чаще всего от программистов требуется желание перебирать все эти ключи. А поскольку карты не могут гарантировать определённый порядок сортировки ключей, то иногда приходится задаваться вопросом, в каком порядке они будут после перебора? Это — следствие того, что интерфейс карты не даёт гарантий по сортировке. И хотя считается, что это не имеет значения, но на практике всё же хочется отсортировать. Так нужно для более эффективной организации данных, например для облегчения проверки уже имеющихся ключей.

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

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

Хочу предложить своё собственное определение утечки абстракций.

Утечкой абстракций (abstraction leak) называется ситуация, когда реализация может влиять на окружение так, как не было предусмотрено интерфейсом.

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

Идея дырявости большинства абстракций не является необоснованной. Это подразумевал и Джоел Сполски в своём «The Law of Leaky Abstractions»:

«Все нетривиальные абстракции являются дырявыми до определённой степени».

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

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

Каждая физическая реализация криптосистемы уязвима к атакам по сторонним каналам.

Учитывая всё сказанное выше, эту идею можно распространить не только на физические, но и на эмулированные реализации.

Оценка и сравнение интерфейсов

Как мы уже видели выше, в интерфейсах на С задаются такие вещи, как тип возвращаемого значения и количество параметров, которые могут быть переданы функции. А что насчёт Python? Я использую термин «интерфейс» в соответствии с контекстом статьи, то есть в более широком понимании по сравнению с тем, что пишут в книгах об «интерфейсах» в Python.

def add_numbers(a,b):
return a + b

print(add_numbers(3,1))
print(add_numbers(“abc”,”def”))

В этом языке нам требуется формализовать типы интерфейса функции. Это упрощает определение и вызов функции, поскольку нужно обработать меньше информации. С другой стороны — ограничений, по которым можно со временем проводить проверку для поиска ошибок, меньше.

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

И есть ряд вещей, которые могут коммуницировать с add_numbers через интерфейс Python.

А теперь взгляните на количество типов интерфейсов, которые мы можем описать в Haskell:

Учитывая этот код, интерфейс add_numbers может получить следующую информацию:

Для конкретного интерфейса на выбранном вами языке можно оценить ещё и количество уникальных способов передачи информации:

• через интерфейс;
• в обход интерфейса через утечки абстракций.

Можете также обратить внимание на следующее:

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

Проанализируем подобным образом графический пользовательский интерфейс, в котором есть возможность менять папки:

А теперь рассмотрим ту же задачу смены папки с помощью командной строки и cd:

В предыдущие две таблицы я не включил такие данные, как количество шума в сигнале. Если сравнить сложность повторения одной и той же последовательности при нажатии клавиш (одна за другой) и движении мыши (пиксель за пикселем), то очевидно, что во втором случае ошибок гораздо больше. В графических интерфейсах это компенсируется благодаря принятию менее строгой семантики. Представьте, если бы на кнопках «OK» и «Cancel» доступная для кликов зона была шириной всего 1 пиксель.

Можно ещё больше усложнить анализ, если оценивать изменение доли ошибок у пользователей с физическими отклонениями.

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

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

Дырявые и ограниченные интерфейсы

Я опишу несколько наблюдений на основании анализа из предыдущего раздела. Но сначала приведу пару определений:

Дырявый интерфейс (leaky interface) — интерфейс, который игнорируется в ходе любых взаимодействий между системой и окружением.

Ограниченный интерфейс (specific interface) — интерфейс с относительно небольшим количеством возможных входов и выходов.

Хороший пример ограниченного интерфейса — кусочно-заданные функции, определённые только для небольшого количества входных данных.

Если вы можете обоснованно оценить «дырявость» или «ограниченность» интерфейсов, то имеет смысл очертить диапазон, на одном конце которого будут очень ограниченные и недырявые интерфейсы, а на другом — неограниченные и дырявые.

Вероятно, вы предложите кого-то подвинуть влево или вправо на шкале, но главное, что вы ухватили идею. Можно даже разбить на две отдельные шкалы: по степени дырявости и строгости. Хотя в целом эти два понятия хорошо коррелируют.

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