Об абстракции в программировании

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

Чтобы пояснить эту мысль, я должен вернуться к временам первопрограммистов. Первые машины вынуждали программиста присутствовать на всех уровнях абстракции - от общего (как правило, математического) алгоритма до его программного эквивалента и даже до машинных тонкостей. В его представлении смешивались объекты всех уровней - скажем, обозначение А матрицы, адрес массива ячеек, который воплощает эту матрицу и, наконец, алгоритмы реализации операций над матрицами и более того, алгоритмы доступа к элементам матрицы и даже вопросы их представления. Первые языки программирования позволили программисту абстрагироваться от конкретных машинных деталей и уменьшить количество уровней абстракции. Именно в этом причина их успеха. Фактически эти языки позволяли программисту работать почти на том же уровне абстракции, какой был в прикладной задаче. Дело в том, что задачи решались хорошо математически определённые, сложные в основном по логике, а математические объекты были самые элементарные - переменная, вектор, матрица. Для тех времён такой абстракции было вполне достаточно - и достаточно сейчас для большинства вычислительных задач. Поэтому нас учили тому, чтобы уметь записывать логику программы. Ведь при таком подходе программирование - это перенесение логики алгоритма на язык программирования, не более того. Всё сводится к логике.

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

Структура абстрактного типа данных

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

• Конструкторы, которые выполняют создание (или построение) объекта абстрактного типа данных путем объединения отдельных компонентов в единое целое; 
•  Селекторы, которые осуществляют выборку какого-либо отдельного компонента абстрактного типа данных; 
•  Операции опроса состояния абстрактного типа данных; 
•  Операции ввода/вывода.

Ссылка: Информация взята с этого источника.