Языки программирования по уровню абстракции + видео обзор

Уровни абстракций — ключ к пониманию архитектурных изысков ПО

Языки программирования по уровню абстракции

Эта статья будет в большей степени полезна новичкам, только начинающим работать с абстракциями и построением архитектур ПО. Однако искренне надеюсь, что и более опытные специалисты смогут найти для себя что-то интересное в этом материале, — пишет Наталия Ништа в своей статье, опубликованной на DOU.UA.

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

Модель объекта и ступень приближения

Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали, не играющие существенной роли в данном приближении. И уровень абстракции — это и есть наша ступень приближения. Каждый человек способен строить абстракции — это отличительная способность homo sapiens. Но не каждый способен делать это достаточно качественно.

Чтобы не вдаваться в многоэтажную теорию, приведу наглядный пример. Итак, раскладываем по полочкам. Представьте себе, что вы решили испечь яблочный пирог. Вы берете толстую кулинарную книгу с полки (для любителей, все остальные — в сеть), открываете нужный вам рецепт и читаете нечто следующее:

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

Если вы осилили текст курсивом, то вы очевидно заметили, что он имеет весьма посредственное отношение к тому, что нам нужно. Собственно, к тому, как же печь эти чертовы пироги из яблок, не правда ли?

Языки программирования по уровню абстракции

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

А ведь что на самом деле нас интересовало в рецепте? Нам нужно было знать, сколько и каких продуктов нам понадобится и что затем с ними делать. Нас абсолютно не интересует в этом приближении (на данном уровне абстракции), каким образом эти продукты к нам попали (более низкие уровни абстракции) и что мы будем делать с этим пирогом потом (более высокие уровни абстракции). Это очевидно. Но тысячи программистов продолжают игнорировать эти принципы и пишут мозговыносные структуры if-if-else-if…

А бывает так, что в рецепте встречаются умные словечки типа «бланшировать» или «сделать бизе». В хороших кулинарных руководствах описание подобных практик выносят в отдельные главы, а в самих рецептах лишь ссылаются на страницы с подробным описанием техники (привет, Инкапсуляция).

Построение структуры

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

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

Языки программирования по уровню абстракции

Абстракция и Реализация

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

Чтобы упростить этот процесс, стоит разобраться в природе дуальности понятий Абстракции и Реализации. В этом моменте обычно и фокусируются на различных курсах по программированию, перед этим упуская понятие уровня абстракции. Из-за чего у студентов формируется заблуждение, что ООП — это что-то запредельно сложное.

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

Таким образом, считать объект абстрактным или реальным — зависит исключительно от степени детализации моделируемого «мира» и от бизнес-задач, поставленных перед архитектором. И, разумеется, от его чувства прекрасного.

Языки программирования по уровню абстракции

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

Источник

21. Языки программирования. Классификация ЯП

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

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

Многие ЯП имеют императивную форму, т.е. описывают последовательность операций. Другие могут иметь декларативную форму, т.е. описывают результат, а не то, как его получить.

Некоторые языки определяются стандартом (C,C++,Haskell, и др.). Другие не имеют формального описания, и наиболее широко распространенная реализация используется в качестве эталона.

Описание ЯП обычно делится на две части: синтаксис, т.е. форма, и семантика, т.е. значение.

Семантика в свою очередь подразделяется на лексику и грамматику.

Лексика определяет какие “слова” могут быть в языке. Это включает названия переменных, функций, числовые константы, строки, и т.п., а так же управляющие символы языка. Грамматика определяет каким образом эти “слова” комбинируются в более сложные выражения.

Не все синтаксически корректные программы являются семантически корректными. Например:

Семантика же подразделяется на статическую, динамическую, и систему типов.

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

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

определяет каким образом ЯП классифицирует значения и выражения, как эти типы взаимодействуют и каким образом ЯП может манипулировать ими. Система типов является практическим приложением теории категорий. Цель системы типов – проверка программы на корректность (до какой-то степени). Любая система типов, отвергая некорректные программы, будет так же отвергать некоторый процент коррекнтых (хотя необычных) программ. Чтобы обойти это ограничение, ЯП обычно имеют некие механизмы для выхода из ограничений системы типов. В большинстве случаев, указание корректных типов ложится на совесть программиста. Однако некоторые ЯП (обычно функциональные) умеют выводить типы исходя из семантики, и таким образом освобождают программиста от необходимости явно указывать типы.

Классификация языков программирования

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

Четкой классификации не существует, по той простой причине, что существуют буквально тысячи ЯП, и в любой категории классификации обнаруживается практически непрерывный спектр.

По системе типов

Наиболее категоричное разделение ЯП по системе типов на типизированные и нетипизированные.

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

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

Типизированные языки определяют типы данных, с которыми работает любая операция. Например, операция деления работает над числами – для строк эта операция не определена.

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

По моменту проверки типов ЯП делятся на статически и динамически типизированные (или просто, статические и динамические).

Статически типизированные языки

При статической типизации, типы всех выражений точно определены до выполнения программы, и обычно проверяются при компиляции. Языки со статической типизацией, в свою очередь могут быть явно типизированными (manifestly typed) или типовыводящими (type-inferred).

Явно типизированные языки

требуют явного указания типов. К ним относятся, например, C, C++, C#, Java.

определяют (выводят) типы большинства выражений автоматически, и требуют явного аннотирования только в сложных и неоднозначных случаях. К ним относятся, например, Haskell и OсaML.

Надо заметить, что многие явно типизированные языки умеют выводить типы в некоторых случаях (например, auto в С++11), поэтому четкую грань здесь провести можно не всегда.

Динамически типизированные языки

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

По строгости типизации языки делятся на сильно и слабо типизированные.

Слабо типизированные языки

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

Сильно типизированные языки

не позволяют неявную конверсию, и требуют явной.

В целом, четкую грань провести оказывается достаточно сложно, поскольку неявное преобразование типов в той или иной мере производится в большинстве языков. Однозначно к слабо типизированным относят Perl, JavaScript и C (в силу свободной конверсии void* ). К сильно типизированным относят C++, Java, Haskell, и другие.

По уровню абстракции

Классификация по уровню абстракции сильно зависит от современных представлений о “высоком уровне абстракции”.

Языки по-настоящему низкого уровня – это машинный код и языки ассемблера, все остальные – в некотором смысле языки высокого уровня. Тем не менее, многие сейчас считают C и C++ языками низкого уровня.

Java, Python, Ruby и т.п. сейчас общепринято считаются языками высокого уровня.

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

По модели исполнения

ЯП может быть компилируемым, транс-компилируемым или интерпретируемым.

Интерпретируемые языки исполняются непосредственно, без этапа компиляции. Программа, называемая интерпретатором, читает каждое выражение, определяет сообразное действие, и совершает его. Гибридный вариант может генерировать машинный код “на лету” и исполнять его.

Интерпретируемые языки: PHP, Perl, Bash, Python, JavaScript, Haskell

Компилируемый язык компилируется, т.е. переводится в исполнимую форму до выполнения.

Компиляция может производиться непосредственно в машинный код, или в какое-либо промежуточное представление (байт-код), которое потом интерпретируется виртуальной машиной.

Компилируемые языки (машинный код): ASM, С, С++, Algol, Fortran Компилируемые языки (байт-код): Python, Java

Транс-компилируемые языки – это языки, которые сперва переводятся в язык более низкого уровня, который в свою очередь уже может быть скомпилирован. Частой целью для транс-компилируемых языков является C, который, в свою очередь, часто является транс-компилируемым в ассемблер.

Транс-компилируемые языки: C, C++, Haskell, Fortran

Линии сильно размыты, поскольку существуют компиляторы для традиционно интерпретируемых языков, и, напротив, интерпретаторы для традиционно компилируемых.

Классификация по “поколению”

Поколение – несколько условная характеристика, которая в значительной мере связана с историей появления современных языков программирования.

Языки первого поколения

1GL – это машинные языки. Исторически, программы на этих языках вводились при помощи переключателей на передней панели ЭВМ, либо “писались” на перфокартах и позже перфолентах. Программа на 1GL состоит из 0 и 1 и сильно привязана к конкретному железу, на котором она должна исполняться.

Языки второго поколения

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

Языки третьего поколения

Более абстрактные, чем 2GL, это языки, которые перекладывают заботу о непринципиальных деталях с плеч программиста на плечи компьютера. Fortran, ALGOL и COBOL являются первыми 2GL. C, C++, Java, BASIC и Pascal так же могут быть отнесены к 3GL, хотя в общем 3GL подразумевает только структурную парадигму (в то время как C++, Java работают в том числе в ООП)

Языки четвертого поколения

Определение несколько расплывчато, однако в целом сводится к еще более высокому уровню абстракции, чем 3GL. Однако, подобный уровень абстракции часто требует сужения области применения. Так, например, FoxPro, LabView G, SQL, Simulink являются 4GL, однако находят применение в узкой специфической области. Некоторые исследователи считают, что 4GL являются подмножеством DSL (domain specific language, язык, специфичный к области).

Языки пятого поколения

В конце 80-х – начале 90-х была попытка разработать класс языков, которые “пишут программы сами”. По идее, программист должен был описывать как программа должна себя вести, а остальное должен был делать компьютер. К примерам можно отнести Prolog, OPS5, Mercury. К добру или худу, но эта затея провалилась, поскольку создание эффективного алгоритма для решения конкретной проблемы – само по себе весьма нетривиальная задача, и часто для ее решения требуются человеческая смекалка и интуиция.

Источник

Уровень абстракции (программирование)

Языки программирования по уровню абстракции

Языки программирования по уровню абстракции

Уровень абстракции предоставляет способ сокрытия деталей реализации определенного множества функциональных возможностей. Модели программного обеспечения, использующие уровни абстракции, включают семиуровневую модель OSI для протоколов передачи данных компьютерных сетей, библиотеку графических примитивов OpenGL, модель ввода-вывода на основе потоков байт из Unix, адаптированную MSDOS, Linux и большинством других современных операционных систем.

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

Большинство графических библиотек, например, OpenGL, предоставляют в качестве интерфейса абстрактную графическую модель. Библиотека отвечает за трансляцию команд, данных программистом, в специальные комадны устройства, необходимые для рисования графических элементов и объектов. Специальные команды устройства для графопостроителя отличаются от команд устройства для ЭЛТ монитора, но графическая библиотека скрывает зависящие от устройства детали реализации, предоставляя абстрактный интерфейс, содержащий набор примитивов, общеупотребимых для рисования графических объектов.

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

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

Известный афоризм Дэвида Уилера гласит: Все проблемы в информатике можно решить на другом уровне окольным путем; [2] это часто неверно цитируется с заменой «окольного пути» на «абстракцию». Продолжение от Кевлина Хенни гласит «. за исключением проблем с большим уровнем косвенности.»

Источник

Многоуровневая абстракция

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

Данная статья содержит лишь теорию. Практической будет следующая статья (постараюсь чередовать).

Многоуровневая абстракция

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

Зачем вообще делят на уровни абстракции?

1. Борьба со сложностью. На каждом уровне применяются методы именно данного уровня.
2. Уменьшение связности.
3. Обеспечение взаимозаменяемости классов на всех уровнях кроме верхнего.

Многоуровневая абстракция работы с данными

Идем по убыванию уровня абстракции:
* Класс-сущность реального мира
* Провайдер данных
* Реальные библиотеки работы с данными

Когда возникают проблемы?

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

Что делать?

Кодогенерация во многих случаях (не всегда) может заменить многоуровневую абстракцию. При этом будут генерироваться конечные классы (из верхнего уровня абстракции), содержащие в себе методы работы с выбранным источником данных.
1. Имея в основе метаданные, мы можем вносить изменения в алгоритмы генерации кода и разом модифицировать всю модель.
2. При наличии метаданных прототип модели можно получить в кратчайший срок.
3. За счет наличия генераторов для каждого источника данных, модель будет сгенерирована с приемлемой оптимальностью работы с выбранным источником данных, учитывая его специфику.

Чем кодогенерация может помочь в сложных моделях

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

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

Кодогенерация + многоуровневая абстрактная модель

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

Источник

Языковые абстракции

3.1. Отступление «об абстрагировании»

Абстрагирование особенно актуально для двух групп языков, которые мы определили как языки моделирования и программирования.

3.2. Абстракция данных

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

3.2.1. Данные и типы данных

3.2.2. Эволюция определения типа данных

Об основном вопросе в области типов данных

3.2.3. Абстрактные типы данных

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

Обоснование применимости концепции абстрактных типов данных в практике программирования было сделано Хоаром (С.A.R. Hoare). Некоторая программа, работающая с данными типа т и содержащая последовательность операторов, реализующих операции с этим типом, может быть преобразована в функционально-эквивалентную программу. В результирующей программе каждая операция с типом т может быть описана в виде функции, а все явно запрограммированные действия с этим типом могут быть заменены вызовами соответствующих функций.

3.2.4. Разновидности полиморфизма

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

О перегрузке
Бьерн Страуструп (Bjarne Stroustrup) в статье «Generalizing Overloading for С++ 2000» (http://www.research.att.com/-bs/papers.html), датируемой 1 апреля 1998 г., предлагает развивать идеи перегрузки в языке C++. Например, предлагается перегружать не только пробелы, но и пропущенные пробелы.

3.2.5. Статический и динамический контроль типов

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

3.2.6. Статически и динамически типизируемые языки программирования

Языки программирования по уровню абстракции

Одним из наиболее интересных динамически типизируемых языков программирования является язык «Автокод Эльбрус» [Сафонов 1989]. При определении переменной целочисленного типа данных отводится лишь области памяти необходимого формата. Например, описание ф64 а указывает на необходимость отведения для переменной а 64-х битов, в которых далее может быть размещено целое число. Динамическая типизация может быть эффективно поддержана аппаратной реализацией (например, архитектура Эльбрус для языка «Автокод Эльбрус»).

3.3. Абстракция управления

3.3.1. Структурное программирование

3.3.2. Визуальное структурное программирование

Языки программирования по уровню абстракции

Языки программирования по уровню абстракции

Обратим внимание на то, что долгое время в Америке отвергалась идея визуального программирования, и основной упор там делался на создание универсального языка программирования.

3.3.3. Оператор перехода

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

3.3.4. Оператор итерации

В некоторых языках программирования итератор традиционно представляется в виде процедуры. Например, так на языке CLU может быть написано суммирование всех элементов множества s с помощью итератора elements (s) (листинг 4.1).

Листинг 4.1. Пример использования итератора

for i: int in intset$elements(s) do

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

which (х: х живет в Старом Петергофе)

3.3.5. Оператор исключения

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

Обратим внимание на то, что многие широко распространенные языки программирования (например, Pascal) не имеют механизма обработки прерываний.

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

Пример структурного предложения языка «Автокод Эльбрус» выглядит так:

Структурный переход по ситуации c1 в закрытом предложении может быть выполнен, например, следующим образом: c1!.

3.3.6. Зависимости по управлению и по данным

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

Пример зависимости по управлению:

< s1; >/*исполнение этого оператора зависит от c1 */

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

3.4. Абстракция модульности

3.4.1. Модульное программирование

3.4.2. Определения модуля и его примеры

3.4.3. Характеристики модульности

Связность (прочность) модуля

Существует гипотеза о глобальных данных, утверждающая, что глобальные данные вредны и опасны. Идея глобальных данных дискредитирует себя так же, как и идея оператора безусловного перехода goto. Локальность данных дает возможность легко читать и понимать модули, а также легко удалять их из программы.

О средствах задания информационной связности
Обратим внимание на то, что средства для задания информационно прочных модулей отсутствовали в ранних языках программирования (например, FORTRAN и даже в оригинальной версии языка Pascal). И только позже, в языке программирования Ada, появился пакет- средство задания информационно прочного модуля.

Источник

Видео

Что такое уровни абстракции и как их различать?

Что такое уровни абстракции и как их различать?

Про абстракции в программировании и АйТи

Про абстракции в программировании и АйТи

Три столпа ООП. Часть IV - Абстракция

Три столпа ООП. Часть IV - Абстракция

Lisp: побеждая посредственность (Пол Грэм)

Lisp: побеждая посредственность (Пол Грэм)

Шпаргалка 02. Уровни абстракции

Шпаргалка 02. Уровни абстракции

ЯЗЫКИ ПРОГРАММИРОВАНИЯ. ЧТО НУЖНО ЗНАТЬ!

ЯЗЫКИ ПРОГРАММИРОВАНИЯ. ЧТО НУЖНО ЗНАТЬ!

Абстракция в ООП

Абстракция в ООП

5 лёгких языков программирования, которые интересно учить!

5 лёгких языков программирования, которые интересно учить!

Основы Python #14: уровни абстракции (мини quasi лаба)

Основы Python #14: уровни абстракции (мини quasi лаба)

😱 САМЫЕ СЛОЖНЫЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ

😱 САМЫЕ СЛОЖНЫЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ
Поделиться или сохранить к себе:
Добавить комментарий

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