Что такое уровень абстракции
Уровень абстракции (программирование)
Уровень абстракции предоставляет способ сокрытия деталей реализации определенного множества функциональных возможностей. Модели программного обеспечения, использующие уровни абстракции, включают семиуровневую модель OSI для протоколов передачи данных компьютерных сетей, библиотеку графических примитивов OpenGL, модель ввода-вывода на основе потоков байт из Unix, адаптированную MSDOS, Linux и большинством других современных операционных систем.
В операционной системе Unix большинство типов операций ввода-вывода рассматриваются как потоки байтов, считываемые или записываемые на устройство. Эта модель потока байтов используется для ввода-вывода в файл, сокет и компьютерный терминал, чтобы обеспечить независимость от устройства ввода-вывода. Для чтения и записи в устройство на уровне приложения программа вызывает функцию открытия устройства, которое может соответствовать реальному устройству, например, терминалу или виртуальному устройству, например, сетевому порту или файлу в файловой системе. Физические характеристики устройства передаются операционной системе, которая, в свою очередь, предоставляет абстрактный интерфейс, позволяющий программисту считывать и записывать байты в устройство. Операционная система затем выполняет действительное преобразование, необходимое для чтения и записи потока байтов в устройство.
Большинство графических библиотек, например, OpenGL, предоставляют в качестве интерфейса абстрактную графическую модель. Библиотека отвечает за трансляцию команд, данных программистом, в специальные комадны устройства, необходимые для рисования графических элементов и объектов. Специальные команды устройства для графопостроителя отличаются от команд устройства для ЭЛТ монитора, но графическая библиотека скрывает зависящие от устройства детали реализации, предоставляя абстрактный интерфейс, содержащий набор примитивов, общеупотребимых для рисования графических объектов.
Хорошая абстракция обобщает то, что можно сделать абстрактным; допуск специфики нарушает абстракцию и ее успешное применение требует приспособления к каждому уникальному требованию или проблеме.
Часто уровни абстракции организуются в иерархию уровней абстракции. Сетевая модель OSI содержит семь уровней абстракции. Каждый уровень модели OSI ISO инкапсулирует и рассматривает отдельную часть требований по организации связи, сокращая таким образом сложность соответствующих инженерных решений.
Известный афоризм Дэвида Уилера гласит: Все проблемы в информатике можно решить на другом уровне окольным путем; [2] это часто неверно цитируется с заменой «окольного пути» на «абстракцию». Продолжение от Кевлина Хенни гласит «. за исключением проблем с большим уровнем косвенности.»
Уровни абстракций — ключ к пониманию архитектурных изысков ПО
Эта статья будет в большей степени полезна новичкам, только начинающим работать с абстракциями и построением архитектур ПО. Однако искренне надеюсь, что и более опытные специалисты смогут найти для себя что-то интересное в этом материале, — пишет Наталия Ништа в своей статье, опубликованной на DOU.UA.
Абстракция — один из набивших оскомину столпов ООП. В любом курсе по программированию с вероятностью 99% можно найти урок-другой, посвященный теме абстракции. И практически всегда упускается более широкое, всеобъемлющее понятие «уровней абстракции» — на мой взгляд, критически важное, ключевое для понимания всех остальных принципов проектирования.
Модель объекта и ступень приближения
Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали, не играющие существенной роли в данном приближении. И уровень абстракции — это и есть наша ступень приближения. Каждый человек способен строить абстракции — это отличительная способность homo sapiens. Но не каждый способен делать это достаточно качественно.
Чтобы не вдаваться в многоэтажную теорию, приведу наглядный пример. Итак, раскладываем по полочкам. Представьте себе, что вы решили испечь яблочный пирог. Вы берете толстую кулинарную книгу с полки (для любителей, все остальные — в сеть), открываете нужный вам рецепт и читаете нечто следующее:
«Чтобы испечь яблочный пирог, нам понадобится два килограмма непременно свежих яблок, румяных, как девичьи щёки на крещенском морозе. Помнится, видал я такие щёчки у моей ненаглядной Лизоньки, когда мы впервые с ней встретились, и она угощала меня яблочными пирогами, состряпанными на последние деньги, которые она выручила от продажи дедовских коллекционных монет 1819 года, выпущенных при императоре таком-то…» И т.д, и т.п.
Если вы осилили текст курсивом, то вы очевидно заметили, что он имеет весьма посредственное отношение к тому, что нам нужно. Собственно, к тому, как же печь эти чертовы пироги из яблок, не правда ли?
А теперь вспомните, как часто в коде нам приходится встречать логические конструкции типа if-if-if-else-if-else-if, содержащие тонны вложенных рассуждений. Приходится читать все эти адские нагромождения и держать в голове всю цепочку событий, для того, чтобы понять, что тут вообще происходит и какое отношение «вот это всё» имеет к заявленному содержанию (название класса/функции по аналогии с названием рецепта «яблочный пирог»).
А ведь что на самом деле нас интересовало в рецепте? Нам нужно было знать, сколько и каких продуктов нам понадобится и что затем с ними делать. Нас абсолютно не интересует в этом приближении (на данном уровне абстракции), каким образом эти продукты к нам попали (более низкие уровни абстракции) и что мы будем делать с этим пирогом потом (более высокие уровни абстракции). Это очевидно. Но тысячи программистов продолжают игнорировать эти принципы и пишут мозговыносные структуры if-if-else-if…
А бывает так, что в рецепте встречаются умные словечки типа «бланшировать» или «сделать бизе». В хороших кулинарных руководствах описание подобных практик выносят в отдельные главы, а в самих рецептах лишь ссылаются на страницы с подробным описанием техники (привет, Инкапсуляция).
Построение структуры
Конечно, бывают и обратные ситуации, когда за тоннами слоёв абстракций невозможно уловить нить повествования. Но в этом-то и состоит мастерство архитектора ПО — спроектировать достаточно простую для сопровождения, то есть понимания, структуру. «Не нужно быть умным — нужно быть понятным» ©.
В то же время, не терять в эффективности решения бизнес-задач. В некоторой мере, это искусство. Каждый конкретный архитектор (программист) будет рисовать эту картину, то есть создавать модель мира по-своему: «Я художник — я так вижу». Вот вам пища в топку холиваров на счет единых стандартов программирования в рамках команды и необходимости наличия исполнителя роли архитектора.
Абстракция и Реализация
Есть ещё один момент, о котором я хочу упомянуть: путешествие между слоями логик. Красиво изолированный уровень абстракции достаточно прост для понимания: у нас есть ряд объектов, очевидным образом взаимодействующих между собой, уровни вложенности маленькие (если они вообще есть — как в рецепте пирога). Однако, как нам уже стало понятно, самым трудозатратным для понимания является перемещение между уровнями абстракций.
Чтобы упростить этот процесс, стоит разобраться в природе дуальности понятий Абстракции и Реализации. В этом моменте обычно и фокусируются на различных курсах по программированию, перед этим упуская понятие уровня абстракции. Из-за чего у студентов формируется заблуждение, что ООП — это что-то запредельно сложное.
Возьмем для примера такую цепочку слоёв абстракций: нам нужен пирог для Дня рождения друга. Спускаемся ниже: пирог может быть фруктовый или мясной. А может, рыбный? В момент рассуждений о том, что нам нужен какой-то пирог в качестве подарка, он (пирог) выступает конечным элементом данного уровня абстракции. В этот момент пирог — это реализация подарка (но он может быть любой: бритва, деньги, конструктор лего — это всё варианты подарка). Когда мы совершаем переход на более низкий уровень абстракции, наш объект (пирог) превращается из конечной реализации в абстракцию: уже нас не устраивает уровень детализации «какой-то пирог», мы начинаем искать его реализацию (привет, Полиморфизм).
Таким образом, считать объект абстрактным или реальным — зависит исключительно от степени детализации моделируемого «мира» и от бизнес-задач, поставленных перед архитектором. И, разумеется, от его чувства прекрасного.
С моей точки зрения, понимая явление уровней абстракций, можно легко разобраться во всех принципах и шаблонах проектирования.
Многоуровневая абстракция
В предыдущей статье мы рассмотрели некоторые подходы к кодогенерации, теперь я хочу взглянуть на многоуровневую абстракцию и произвести некоторый анализ.
Данная статья содержит лишь теорию. Практической будет следующая статья (постараюсь чередовать).
Многоуровневая абстракция
Многоуровневая абстракция — разделение компонента приложения на несколько уровней абстракции так, что на каждом уровне абстракция согласована. Это несколько заумно может звучать. Суть в том, чтобы разделить компонент на несколько уровней, таким образом, чтобы мы могли относительно автономно работать с данным уровнем в его абстракции и не держать в голове информацию о других уровнях.
Зачем вообще делят на уровни абстракции?
1. Борьба со сложностью. На каждом уровне применяются методы именно данного уровня.
2. Уменьшение связности.
3. Обеспечение взаимозаменяемости классов на всех уровнях кроме верхнего.
Многоуровневая абстракция работы с данными
Идем по убыванию уровня абстракции:
* Класс-сущность реального мира
* Провайдер данных
* Реальные библиотеки работы с данными
Когда возникают проблемы?
1. Обычно в одном проекте несколько многоуровневых абстрактных моделей. Проблемы возникают если несколько абстрактных моделей надо подвергнуть однообразным изменениям. При этом приходится вносить изменения во все промежуточные уровни абстракции включая верхний.
2. При прототипировании накладные расходы на проектирование многоуровневой абстрактной модели могут быть слишком высоки и возможно написание временного кода без уровней абстракции, который придется выкинуть после утверждения прототипа.
3. Абстракция от источников данных может породить (и порой порождает) неоптимальную работу с источниками данных.
Что делать?
Кодогенерация во многих случаях (не всегда) может заменить многоуровневую абстракцию. При этом будут генерироваться конечные классы (из верхнего уровня абстракции), содержащие в себе методы работы с выбранным источником данных.
1. Имея в основе метаданные, мы можем вносить изменения в алгоритмы генерации кода и разом модифицировать всю модель.
2. При наличии метаданных прототип модели можно получить в кратчайший срок.
3. За счет наличия генераторов для каждого источника данных, модель будет сгенерирована с приемлемой оптимальностью работы с выбранным источником данных, учитывая его специфику.
Чем кодогенерация может помочь в сложных моделях
Сложные приложения всегда задают много вопросов. По моим наблюдениям, на бОльшую часть из них можно ответить еще в процессе разработки (например, на сайте нужно кеширование или нет; какая операционная система будет на сервере; использовать буфферизацию вывода или нет. ). Если мы ответим на этим вопросы заранее — мы можем избежать лишней сложности программы, лишних действий, лишних проверок и т.п. Более того, кодогенератор сам может собрать в среде назначения некоторые данные заранее, которые он может использовать для оптимизации работы.
Но это не значит, что меньше результирующего кода = проще система. Кодогенератор сам должен быть достаточно качественный для того, чтобы генерировать качественный код.
Кодогенерация + многоуровневая абстрактная модель
В следующей статье мы разработаем определенный несложный кодогенератор.
Зачем нужны абстракции и интерфейсы
И что это вообще такое?
Как в старом анекдоте: про объектно-ориентированное программирование можно рассказать просто и неправильно либо сложно и неправильно. Мы попробуем рассказать про очередной аспект ООП просто.
Зачем это: ООП — одна из главных концепций современной разработки. Она применима не к каким-то конкретным языкам, это скорее способ мышления в программировании. Если вы понимаете ООП, ваш код на любом языке будет чище, читаемее и эффективнее.
В этой статье разберём два сложных понятия из объектно-ориентированного программирования: абстракции и интерфейсы. Это ещё одна ступень в понимании непостижимого.
Основные идеи из ООП
Абстракция
Представьте, что вы попросили нескольких человек описать в общих чертах, что такое телефон и как им пользоваться: пусть это будут бабушка, мама и подруга. Бабушка вспомнит про дисковые телефоны и трубки с витым проводом. Мама расскажет про радиотелефоны, у которых есть база и есть трубка, с которой можно ходить по всей квартире, а подруга начнёт описывать мобильник.
Несмотря на то что рассказы будут сильно отличаться между собой, у них будет несколько общих моментов про телефон:
Получается, что если представить абстрактный телефон, то получится такое устройство с динамиком, микрофоном и средством набора номера.
Это и есть абстракция: когда мы описываем только самые существенные детали, которые важны для задачи. В нашем случае задача такая — понять, что такое телефон и как им пользоваться. Поэтому микрофон и динамик для этой задачи важен, а способ связи телефона с сетью — нет. Устройство набора номера важно, а то, какая мелодия играет при вызове — нет.
🔥 Абстракция — это когда мы сосредотачиваемся только на существенных для задачи деталях и игнорируем всё остальное. В ООП абстракция означает, что для каждого объекта мы задаём минимальное количество методов, полей и описаний, которые позволят нам решить задачу. Чем меньше характеристик, тем лучше абстракция, но ключевые характеристики убирать нельзя.
Чтобы работать с абстракциями, используют интерфейсы.
Интерфейс
Итак, у нас есть некое устройство с трубкой, микрофоном, динамиком и средством набора номера. Но если вы вспомните рассказы мамы, бабушки и подруги, то обнаружите вот что:
Всё это — интерфейсы. Они позволяют работать с объектом, не вникая в то, как он устроен внутри. Если вы умеете работать с интерфейсом номеронабирателя, то вам всё равно, нужно ли крутить диск, нажимать физические кнопки на радиотрубке или давить пальцем на сенсорный экран.
Такой интерфейс как бы говорит нам — я передам в телефон любые цифры, какие захочешь. Как я это сделаю внутри и как они будут обработаны — неважно, просто набери номер, а дальше телефон сам разберётся.
Интерфейсы — это действия над объектом, доступные другим объектам (поэтому они называются публичными).
Есть ещё инкапсулированные, то есть внутренние методы. Например, у микрофона есть публичный метод «Слушать голос», и есть внутренний метод «Преобразовать голос в электрические сигналы». С его помощью он взаимодействует с другими частями нашего абстрактного телефона. Про инкапсуляцию будет отдельный материал, потому что тема большая.
Сложная терминология
Строго говоря, интерфейсы — это не действия, а методы. Сейчас объясним.
В программировании есть операции — это простейшие действия, например, скопировать значение из одной переменной в другую.
Из простых действий составляются функции — это когда несколько операций «склеиваются» в нечто единое. Мы даём этой склейке название и получаем функцию. Например, может быть функция «проверить правильность электронного адреса», которая состоит из нескольких десятков простых операций.
На языке ООП функции, привязанные к объектам, называются методами. Просто такой термин. По сути это функции, то есть склеенные вместе операции.
Итого: метод — это набор простых действий, которые склеили в единое целое и засунули в объект.
Для чего это всё
Допустим, вы работаете в команде над большим продуктом. В таких случаях удобно разделить одну большую программу на множество мелких подпрограмм и сервисов, каждый из которых решает свою узкую задачу.
Если заранее не договориться о том, как эти компоненты обмениваются данными между собой, то может случиться то, о чём мы уже предупреждали:
Чтобы такого не было, поступают так:
Абстракции в глазах смотрящего
Один из самых часто встречающихся мне споров — спор о выборе нужного уровня абстракции при кодинге. Граница между перегруженностью и ненужной многословностью очень размыта, она стала одним из причин бесконечных дебатов.
К сожалению, маловероятно, что эти споры будут когда-нибудь решены, по одной простой причине — универсального правильного ответа не существует. Простота кода в глазах смотрящего. Точнее, она сильно зависит от способности читающего воспринимать абстракции. То, что одному кажется чрезвычайным усложнением, идеально выразительно и понятно для другого. И оба имеют полное право на восхваление/порицание кода, а любые изменения идут одному из них в ущерб.
Простой пример
Некоторые считают, что все абстракции снижают простоту, но это неправда. Для примера изучим два фрагмента кода:
Первый фрагмент кода вообще не требует знать от вас абстракции Multimap. Вся функциональность второго примера в первом примере достигнута при помощи простого Map и ничего больше. Взгляните, как же просто! Если производительность нас не волнует, то, возможно, стоит отойти и от абстракции Map, использовав вместо неё просто примитивные массивы?
Тем не менее, многие сочтут, что со вторым фрагментом кода работать проще и легче. Особенно те, кому знакомы Multimap. После того, как поймёшь абстракцию, реализовав её один раз и многократно её применив, то получишь более простой код — единственное put() содержит в себе большой объём знаний в легко усваиваемом виде. В психологии это называется «группированием» и является важным инструментом из арсенала мозга для управления сложностью.
Открытость к абстракциям
Однако недостаток второго подхода заключается в том, что когда с этим кодом встречается тот, кто ещё не «грокнул» эту абстракцию, она покажется ему более сложной, чем первый пример. Ему не просто сначала придётся осознавать эту абстракцию, он должен будет понять абстракцию целиком, а не только использованные в коде части.
Хуже того — для понимания этой абстракции ему нужно будет изучить что-то другое (совершенно другой метод/класс, который, в свою очередь, может ссылаться на ещё какие-то методы и классы). А потом возвращаться к коду, чтобы понять, как абстракция использована в этом конкретном контексте.
И в этом заключается причина трений. То, что одному кажется очень простым, кому-то другому кажется переусложнённым. И оба они правы — было бы ошибкой говорить, что код универсально «прост» или «сложен». Он «прост» или «сложен» только для читающего.
Приведённый выше пример может показаться надуманным, и это справедливо. Я намеренно выбрал абстракцию, которую легко понять, чтобы показать, что абстракции могут упрощать код. Это стоит подчеркнуть, потому что очень просто попасть в ловушку восприятия «абстракции всегда усложняют код». Когда дело касается абстракций, которые мы хорошо понимаем, то легко увидеть, что это не так. Реальная сложность возникает из-за абстракций, с которыми читающий ещё не сталкивался.
Допустим, в вашей кодовой базе есть какой-то многократно повторяющийся «паттерн».
Алиса видит, что этот паттерн можно выделить в полноценную абстракцию. Что эту абстракцию можно перенести в собственный класс или вспомогательный метод, чтобы её можно было логически сгруппировать и лаконично вызывать из различных мест. Боб способен понять достаточно быстро и считает, что код стал намного проще. Кэрол гораздо сложнее понять эту абстракцию, и она считает новый код переусложнённым бардаком.
За этим следуют оживлённые споры о том, является ли код «хорошим» или «плохим». Каждый думает, что он прав, и что код нужно изменить в соответствии с его мнением. Ни одна из сторон не осознаёт, что правы обе — тот же код, который Боб считает более простым для понимания, теперь стал сложнее для понимания Кэрол.
Важность выбора инструментов
Но это только половина истории. Очень важную роль могут играть и инструменты. Использование абстракций, вспомогательных методов и сторонних утилит может значительно повысить читаемость кода для разработчиков, применяющих мощные инструменты, например IDE. Просмотр нужного вспомогательного метода и переход к нему для лучшего понимания его нюансов становится вопросом одного клика.
Однако если разработчик предпочитает писать код в «Блокноте», тот же код становится понимать экспоненциально дольше. Ему приходиться использовать инструменты типа grep, чтобы сначала найти конкретный файл, содержащий код, открыть этот файл, перейти к конкретному методу и повторять весь этот процесс для каждого метода/абстракции, на которые выполняются рекурсивные ссылки.
Первый тип разработчиков с большей вероятностью предпочтёт краткость и сокрытие информации с помощью таких техник ООП, как вспомогательные классы/методы. Второй тип обычно склонен к встраиванию кода. «Просто помести всё в один файл, чтобы я мог прочитать весь код за раз!» Снова возникают перепалки относительно того, что «хорошо» и «плохо». Но ни одна из сторон не является правой или неправой — обе они оптимизируют собственную продуктивность в условиях ограничений своих инструментов.
Каков твой уровень абстракции?
Это приводит нас к неудобной правде об абстракциях. Будучи объективными, стремящимися к равенству инженерами, мы любим считать, что «хороший» код «хорош» для каждого, и что все программисты способны увидеть и оценить «хороший» код.
К сожалению, это просто неправда. «Хорошесть» кода совершенно относительна. То, что «хорошо» для одного, может быть «переусложнённым уродством» для другого, и «дублированным многословным бардаком» для третьего.
Такая ситуация складывается не потому, что «хороший код» субъективен, это не так. Хороший код по определению объективно очень хорошо влияет на продуктивность программистов. К сожалению, один и тот же код может повысить производительность одних разработчиков и снизить продуктивность других.
В качестве полезной аналогии можно привести уровень чтения. Уровни чтения людей сильно варьируются, и их читательские предпочтения сильно коррелируют с уровнем чтения. Некоторым читателям больше подходит использование кратких и абстрактных слов, описывающих сложные мысли. Такие читатели ценят использование слов наподобие «капитулировать», «солидарность» и даже «абстрактный».
Другим же такие слова кажутся раздражающими и им больше подходят их более простые аналоги. Такими аналогами могут быть «сдаться», «поддержка», «высокого уровня» … или просто замена слова целой фразой, выражающей ту же мысль. Аналоги при этом более многословны или не передают то же богатство значений.
То же самое можно сказать и о способности читать код. Некоторые программисты «читают» на уровне выпускников вузов. Они способны быстро понимать абстракции, даже многоуровневые, ценить вносимую ими краткость и логическое группирование. Они отдают преимущество таким принципам, как Don’t-Repeat-Yourself, Single-Level-of-Abstraction и Small-Functions.
А некоторые программисты «читают» на уровне шестого класса школы. Им очень сложно понимать абстракции и умещать в своей голове разные уровни абстракций. Они предпочитают меньшее количество уровней абстракций, даже если это означает многократное повторение или встраивание всей функциональности.
Оба типа программистов будут утверждать, что их цель — простота. И оба типа правы. Реальное отличие между ними в том, что один использует абстракции как инструмент для борьбы со сложностью, а другой воспринимает абстракции как причину сложности.
Ищем баланс
Часто говорят о «правильных» и «неправильных» способах писать код, и во многих случаях это очень полезно. Некоторые абстракции обеспечивают замечательную краткость и группирование, оставаясь при этом простыми и лёгкими в понимании. Допустим, никто и не мечтает встраивать в код такие абстракции, как ArrayList, или HashMap, или Heap.
Но существуют и другие абстракции, обычно сокрытые от глаз в плохо поддерживаемых кодовых базах. Они обеспечивают минимальную краткость, оставаясь комплексными и сложными в понимании.
Во многих случаях вторые можно рефакторить в первые таким образом, чтобы новый код объективно был качественнее старого. Если такие возможности существуют, то мы определённо должны ими пользоваться и совершенствовать свои способности в создании правильно спроектированных абстракций. Писатели книг часто призывают по возможности пользоваться словами попроще, и то же самое определённо справедливо и для программистов.
Однако как бы мы не старались, всегда существуют трения между предоставляемыми абстракциями преимуществами и усилиями, необходимыми для понимания этих абстракций. Когда такие трения выходят на поверхность, нужно осознать, что не существует «правильных» или «ошибочных» ответов, и что нужно соответствовать уровню способностей своей аудитории.
Здесь нам сильно поможет описанная выше аналогия с чтением. Если вы Дональд Трамп, то лучше всего общаться со своей аудиторией, разговаривая на уровне пятого класса школы. Если же вы автор, пищущий для NYTimes, то аудитории больше подойдёт, если вы будете писать на уровне десятого класса.
Если вы один из тех, кто недолюбливает используемые коллегами абстракции, задайтесь вопросом — есть ли способ упростить эти абстракции, сохранив при этом их преимущества. Если да, то вы нашли более совершенное решение и вам стоит рекомендовать его в качестве альтернативы. Если нет, то, вероятно, вам стоит попробовать повысить свой «уровень чтения». Этот навык послужит вам хорошую службу на протяжении всей карьеры.
Если вы один из тех, чьи коллеги постоянно жалуются на «переусложнённость» (overengineering) кода, задайтесь вопросом — есть ли способ сделать его проще без добавления излишней многословности. Если да, то это определённо стоит сделать. Если нет, примите тот факт, что ваши абстракции недостаточно доступны для коллег. Соответствуйте своей истинной, а не желаемой аудитории.
NYTimes не случайно пишет на уровне десятого класса, а ABC news — на гораздо более простом уровне. Ни один из источников нельзя назвать «правым» или «неправым» — оба они обслуживают свою целевую аудиторию. Стремитесь поступать так же в своём коде.
На правах рекламы
VDSina предлагает безопасные серверы на Linux или Windows — выбирайте одну из предустановленных ОС, либо устанавливайте из своего образа.