Создание обёрток (wrappers)
Частой практикой в программировании является написание обёрток. Задача обёртки – сброс сложности в программировании, недопущение «расползания» неудачных API по коду: ведь API третьих сторон не всегда идеально подогнаны к решаемой задаче. Мало того, API бывают неудобно спроектированы.
Мы каждый день работаем с браузером и для нашей задачи надо взглянуть на него под новым углом.
Что такое браузер?
Это движок (engine), машина, выполняющая блочные вычислений над XML/HTML для рендеринга изображения. Код данного движка писался годами и имеет размер в десятки мегабайт кода на C++. Встроенная в движок JavaScript-машина позволяет писать «тонкие» прослойки над API движка браузера.
API браузера по ряду причин написаны мягко говоря «криво». Виной тому и исторические причины – движение web-технологий от статического к динамическому WEB, и субъективные – пресловутые «войны браузеров», во время которых IT-гиганты включали в свои браузеры заведомо несовместимые технологии. Одно это уже требовало написание обёрток, чтобы «отвязаться» от особенностей конкретного браузера.
Пресловутые «костыли» к IE приходится ставить и поныне...
Каковы этапы написания обёртки?
Первый этап — селекция API: выбор наиболее полезных и удачных решений, используемых в проекте в дальнейшем.
Второй этап — накопление статистики. Здесь следует остановиться подробнее. Ведь именно это и делает процесс разработки итеративным: мы узнаём частоту использования тех или иных функций и программных конструкций, а заем выносим наиболее часто используемые из них в отдельные API, классы или субсистемы.
Точно так же по мере использования программной системы или продукта конечными пользователями, мы узнаём наиболее часто выполняемые пользователями операции, отсюда возникает необходимость адаптировать продукт особенно какое-то время после запуска. И это объективные причины, от которых даже при самом тщательном проектировании не удаётся уйти.
Третий этап – создание обёртки. Хорошая обёртка должна сбрасывать сложность пользования API, унифицировать вводимый API в соответствии с внутренними требованиями к оформлению кода продукта, покрывать наиболее часто пользуемые случаи и операции.
Возьмём, например, часто пользуемые API браузера для передачи данных – это XHR (XMLHttpRequest) и WebSocket. Возможности этих API схожи: и там и там мы посылаем данные серверу, получаем от него ответы, ловим события об ошибках от браузерного движка.
Значит, можно написать одну логику, которая будет единообразно выполнять такие операции и две небольшие обёртки над XHR и WebSocket – abstraction layer, скрывающий внутренние реализации и различия между WebSocket и XHR.
Хороший разработчик удачно покрывает обёртками пользуемые API. Отсюда высок спрос и высока оплата работы таких специалистов. Кем быть вам и желаем.
Есть вопрос? Напишите в комментариях!
